contrib.txt 2.9 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758
  1. 1 Introduction
  2. This document describes some guidelines for people participating
  3. in lwIP development.
  4. 2 How to contribute to lwIP
  5. Here is a short list of suggestions to anybody working with lwIP and
  6. trying to contribute bug reports, fixes, enhancements, platform ports etc.
  7. First of all as you may already know lwIP is a volunteer project so feedback
  8. to fixes or questions might often come late. Hopefully the bug and patch tracking
  9. features of Savannah help us not lose users' input.
  10. 2.1 Source code style:
  11. 1. do not use tabs.
  12. 2. indentation is two spaces per level (i.e. per tab).
  13. 3. end debug messages with a trailing newline (\n).
  14. 4. one space between keyword and opening bracket.
  15. 5. no space between function and opening bracket.
  16. 6. one space and no newline before opening curly braces of a block.
  17. 7. closing curly brace on a single line.
  18. 8. spaces surrounding assignment and comparisons.
  19. 9. don't initialize static and/or global variables to zero, the compiler takes care of that.
  20. 10. use current source code style as further reference.
  21. 2.2 Source code documentation style:
  22. 1. JavaDoc compliant and Doxygen compatible.
  23. 2. Function documentation above functions in .c files, not .h files.
  24. (This forces you to synchronize documentation and implementation.)
  25. 3. Use current documentation style as further reference.
  26. 2.3 Bug reports and patches:
  27. 1. Make sure you are reporting bugs or send patches against the latest
  28. sources. (From the latest release and/or the current Git sources.)
  29. 2. If you think you found a bug make sure it's not already filed in the
  30. bugtracker at Savannah.
  31. 3. If you have a fix put the patch on Savannah. If it is a patch that affects
  32. both core and arch specific stuff please separate them so that the core can
  33. be applied separately while leaving the other patch 'open'. The preferred way
  34. is to NOT touch archs you can't test and let maintainers take care of them.
  35. This is a good way to see if they are used at all - the same goes for unix
  36. netifs except tapif.
  37. 4. Do not file a bug and post a fix to it to the patch area. Either a bug report
  38. or a patch will be enough.
  39. If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area.
  40. 5. Patches should be specific to a single change or to related changes. Do not mix bugfixes with spelling and other
  41. trivial fixes unless the bugfix is trivial too. Do not reorganize code and rename identifiers in the same patch you
  42. change behaviour if not necessary. A patch is easier to read and understand if it's to the point and short than
  43. if it's not to the point and long :) so the chances for it to be applied are greater.
  44. 2.4 Platform porters:
  45. 1. If you have ported lwIP to a platform (an OS, a uC/processor or a combination of these) and
  46. you think it could benefit others[1] you might want discuss this on the mailing list. You
  47. can also ask for Git access to submit and maintain your port in the contrib Git module.