mirror of
https://github.com/lwip-tcpip/lwip.git
synced 2024-12-28 09:19:53 +00:00
52 lines
3.1 KiB
Plaintext
52 lines
3.1 KiB
Plaintext
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.
|
|
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:
|
|
|
|
- indentation is two spaces per level, no tabs.
|
|
- end debug messages with a trailing newline (\n).
|
|
- no space between function and opening bracket.
|
|
- one space between keyword and opening bracket.
|
|
- one space and no newline before opening curly braces.
|
|
- spaces surrounding assignment and comparisons.
|
|
- use current source code style as further reference.
|
|
|
|
Source code self documentation style:
|
|
|
|
- JavaDoc compliant and Doxygen compatible.
|
|
- Function documentation above functions in .c files, not .h files.
|
|
- Use current documentation style as further reference.
|
|
|
|
Bug reports and patches:
|
|
|
|
- Make sure you are reporting bugs or send patches against the latest sources.That usually means code in CVS
|
|
- 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's 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.
|
|
|
|
For 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] - 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.
|