From 0fc282e18265bef050d9aba832712a25936483ab Mon Sep 17 00:00:00 2001 From: likewise Date: Wed, 4 Jun 2003 20:00:11 +0000 Subject: [PATCH] Numerated contents so that they can be refered to. --- doc/contrib.txt | 87 ++++++++++++++++++++++++++----------------------- 1 file changed, 46 insertions(+), 41 deletions(-) diff --git a/doc/contrib.txt b/doc/contrib.txt index 252724ab..7c46561f 100644 --- a/doc/contrib.txt +++ b/doc/contrib.txt @@ -1,4 +1,9 @@ -How to contribute to lwIP +1 Introduction + +This document describes some guidelines for people participating +in lwIP development. + +2 How to contribute to lwIP Here is a short list of suggestions to anybody working with lwIP and trying to contribute bugreports, fixes, enhancements, platform ports etc. @@ -6,53 +11,53 @@ First of all as you may already know lwIP is a volunteer project so feedback to fixes or questions might often come late. Hopefully the bug and patch tracking features of Savannah help us not lose users' input. -Source code style: +2.1 Source code style: -- do not use tabs. -- indentation is two spaces per level. -- end debug messages with a trailing newline (\n). -- one space between keyword and opening bracket. -- no space between function and opening bracket. -- one space and no newline before opening curly braces of a block. -- spaces surrounding assignment and comparisons. -- use current source code style as further reference. +1. do not use tabs. +2. identation is two spaces per level. +3. end debug messages with a trailing newline (\n). +4. one space between keyword and opening bracket. +5. no space between function and opening bracket. +6. one space and no newline before opening curly braces of a block. +7. spaces surrounding assignment and comparisons. +8. use current source code style as further reference. -Source code documentation style: +2.2 Source code documentation style: -- JavaDoc compliant and Doxygen compatible. -- Function documentation above functions in .c files, not .h files. - (This forces you to synchronize documentation and behaviour.) -- Use current documentation style as further reference. +1. JavaDoc compliant and Doxygen compatible. +2. Function documentation above functions in .c files, not .h files. + (This forces you to synchronize documentation and behaviour.) +3. Use current documentation style as further reference. -Bug reports and patches: +2.3 Bug reports and patches: -- Make sure you are reporting bugs or send patches against the latest - sources. (From the latest release and/or the current CVS sources.) -- If you think you found a bug make sure it's not already filed in the - bugtracker at Savannah. -- If you have a fix put the patch on Savannah. If it is a patch that affects - both core and arch specific stuff please separate them so that the core can - be applied separately while leaving the other patch 'open'. The prefered way - is to NOT touch archs you can't test and let maintainers take care of them. - This is a good way to see if they are used at all - the same goes for unix - netifs except tapif. -- Do not file a bug and post a fix to it to the patch area. Either a bug report -or a patch will be enough. -If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area. -- Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two) -can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded -as to allow for loss of fixes. Putting bugs on Savannah and subsequently closing them is too much an overhead -for reporting a compiler warning fix. -- Patches should be specific to a single change or to related changes.Do not mix bugfixes with spelling and other -trivial fixes unless the bugfix is trivial too.Do not reorganize code and rename identifiers in the same patch you -change behaviour if not necessary.A patch is easier to read and understand if it's to the point and short than -if it's not to the point and long :) so the chances for it to be applied are greater. +1. Make sure you are reporting bugs or send patches against the latest + sources. (From the latest release and/or the current CVS sources.) +2. If you think you found a bug make sure it's not already filed in the + bugtracker at Savannah. +3. If you have a fix put the patch on Savannah. If it is a patch that affects + both core and arch specific stuff please separate them so that the core can + be applied separately while leaving the other patch 'open'. The prefered way + is to NOT touch archs you can't test and let maintainers take care of them. + This is a good way to see if they are used at all - the same goes for unix + netifs except tapif. +4. Do not file a bug and post a fix to it to the patch area. Either a bug report + or a patch will be enough. + If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area. +5. Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two) + can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded + as to allow for loss of fixes. Putting bugs on Savannah and subsequently closing them is too much an overhead + for reporting a compiler warning fix. +6. Patches should be specific to a single change or to related changes.Do not mix bugfixes with spelling and other + trivial fixes unless the bugfix is trivial too.Do not reorganize code and rename identifiers in the same patch you + change behaviour if not necessary.A patch is easier to read and understand if it's to the point and short than + if it's not to the point and long :) so the chances for it to be applied are greater. -For platform porters: +2.4 Platform porters: -- If you've ported lwIP to a platform (an OS, a uC/processor or a combination of these) and you think it -could benefit others[1] you might want to post an url to a tarball or zip from which it can be imported -to the contrib CVS module. Then you get CVS access and have to maintain your port :) +1. If you've ported lwIP to a platform (an OS, a uC/processor or a combination of these) and you think it + could benefit others[1] you might want to post an url to a tarball or zip from which it can be imported + to the contrib CVS module. Then you get CVS access and have to maintain your port :) [1] - lwIP CVS should not be just a place to keep your port so you don't have to set up your own CVS :) Especially welcome are ports to common enough OS/hardware that others can have access too.