Add third_party libs

1 files changed, 63 insertions, 0 deletions

diff --git a/third_party/lwip-1.4.1/doc/contrib.txt b/third_party/lwip-1.4.1/doc/contrib.txt
new file mode 100644
index 0000000..3057beb
--- /dev/null
+++ b/third_party/lwip-1.4.1/doc/contrib.txt
@@ -0,0 +1,63 @@
+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 bug reports, 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.

+

+2.1 Source code style:

+

+1. do not use tabs.

+2. indentation is two spaces per level (i.e. per tab).

+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. closing curly brace on a single line.

+8. spaces surrounding assignment and comparisons.

+9. don't initialize static and/or global variables to zero, the compiler takes care of that.

+10. use current source code style as further reference.

+

+2.2 Source code documentation style:

+

+1. JavaDoc compliant and Doxygen compatible.

+2. Function documentation above functions in .c files, not .h files.

+   (This forces you to synchronize documentation and implementation.)

+3. Use current documentation style as further reference.

+ 

+2.3 Bug reports and patches:

+

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

+

+2.4 Platform porters:

+

+1. If you have 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 discuss this on the mailing list. You

+   can also ask for CVS access to submit and maintain your port in the contrib CVS module.

+   
\ No newline at end of file