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. |
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. |