/[lwip]/lwip/doc/contrib.txt
ViewVC logotype

Diff of /lwip/doc/contrib.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.6 by likewise, Thu May 1 13:24:01 2003 UTC revision 1.7 by likewise, Wed Jun 4 20:00:11 2003 UTC
# Line 1  Line 1 
1  How to contribute to lwIP  1 Introduction
2    
3    This document describes some guidelines for people participating
4    in lwIP development.
5    
6    2 How to contribute to lwIP
7    
8  Here is a short list of suggestions to anybody working with lwIP and  Here is a short list of suggestions to anybody working with lwIP and
9  trying to contribute bugreports, fixes, enhancements, platform ports etc.  trying to contribute bugreports, fixes, enhancements, platform ports etc.
# Line 6  First of all as you may already know lwI Line 11  First of all as you may already know lwI
11  to fixes or questions might often come late. Hopefully the bug and patch tracking  to fixes or questions might often come late. Hopefully the bug and patch tracking
12  features of Savannah help us not lose users' input.  features of Savannah help us not lose users' input.
13    
14  Source code style:  2.1 Source code style:
15    
16  - do not use tabs.  1. do not use tabs.
17  - indentation is two spaces per level.  2. identation is two spaces per level.
18  - end debug messages with a trailing newline (\n).  3. end debug messages with a trailing newline (\n).
19  - one space between keyword and opening bracket.  4. one space between keyword and opening bracket.
20  - no space between function and opening bracket.  5. no space between function and opening bracket.
21  - one space and no newline before opening curly braces of a block.  6. one space and no newline before opening curly braces of a block.
22  - spaces surrounding assignment and comparisons.  7. spaces surrounding assignment and comparisons.
23  - use current source code style as further reference.  8. use current source code style as further reference.
24    
25  Source code documentation style:  2.2 Source code documentation style:
26    
27  - JavaDoc compliant and Doxygen compatible.  1. JavaDoc compliant and Doxygen compatible.
28  - Function documentation above functions in .c files, not .h files.  2. Function documentation above functions in .c files, not .h files.
29    (This forces you to synchronize documentation and behaviour.)     (This forces you to synchronize documentation and behaviour.)
30  - Use current documentation style as further reference.  3. Use current documentation style as further reference.
31    
32  Bug reports and patches:  2.3 Bug reports and patches:
33    
34  - Make sure you are reporting bugs or send patches against the latest  1. Make sure you are reporting bugs or send patches against the latest
35    sources. (From the latest release and/or the current CVS sources.)     sources. (From the latest release and/or the current CVS sources.)
36  - If you think you found a bug make sure it's not already filed in the  2. If you think you found a bug make sure it's not already filed in the
37    bugtracker at Savannah.     bugtracker at Savannah.
38  - If you have a fix put the patch on Savannah. If it is a patch that affects  3. If you have a fix put the patch on Savannah. If it is a patch that affects
39    both core and arch specific stuff please separate them so that the core can     both core and arch specific stuff please separate them so that the core can
40    be applied separately while leaving the other patch 'open'. The prefered way     be applied separately while leaving the other patch 'open'. The prefered way
41    is to NOT touch archs you can't test and let maintainers take care of them.     is to NOT touch archs you can't test and let maintainers take care of them.
42    This is a good way to see if they are used at all - the same goes for unix     This is a good way to see if they are used at all - the same goes for unix
43    netifs except tapif.     netifs except tapif.
44  - Do not file a bug and post a fix to it to the patch area. Either a bug report  4. Do not file a bug and post a fix to it to the patch area. Either a bug report
45  or a patch will be enough.     or a patch will be enough.
46  If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area.     If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area.
47  - Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two)  5. Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two)
48  can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded     can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded
49  as to allow for loss of fixes. Putting bugs on Savannah and subsequently closing them is too much an overhead     as to allow for loss of fixes. Putting bugs on Savannah and subsequently closing them is too much an overhead
50  for reporting a compiler warning fix.     for reporting a compiler warning fix.
51  - Patches should be specific to a single change or to related changes.Do not mix bugfixes with spelling and other  6. Patches should be specific to a single change or to related changes.Do not mix bugfixes with spelling and other
52  trivial fixes unless the bugfix is trivial too.Do not reorganize code and rename identifiers in the same patch you     trivial fixes unless the bugfix is trivial too.Do not reorganize code and rename identifiers in the same patch you
53  change behaviour if not necessary.A patch is easier to read and understand if it's to the point and short than     change behaviour if not necessary.A patch is easier to read and understand if it's to the point and short than
54  if it's not to the point and long :) so the chances for it to be applied are greater.     if it's not to the point and long :) so the chances for it to be applied are greater.
55    
56  For platform porters:  2.4 Platform porters:
57    
58  - If you've ported lwIP to a platform (an OS, a uC/processor or a combination of these) and you think it  1. If you've ported lwIP to a platform (an OS, a uC/processor or a combination of these) and you think it
59  could benefit others[1] you might want to post an url to a tarball or zip from which it can be imported     could benefit others[1] you might want to post an url to a tarball or zip from which it can be imported
60  to the contrib CVS module. Then you get CVS access and have to maintain your port :)     to the contrib CVS module. Then you get CVS access and have to maintain your port :)
61    
62  [1] - lwIP CVS should not be just a place to keep your port so you don't have to set up your own CVS :)  [1] - lwIP CVS should not be just a place to keep your port so you don't have to set up your own CVS :)
63  Especially welcome are ports to common enough OS/hardware that others can have access too.  Especially welcome are ports to common enough OS/hardware that others can have access too.

Legend:
Removed from v.1.6  
changed lines
  Added in v.1.7

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26