8 |
|
|
9 |
|
|
10 |
The suggestions: |
The suggestions: |
11 |
|
- Make sure you are reporting bugs or send patches against the latest sources.That usually means code in CVS |
12 |
- If you think you found a bug make sure it's not already filed in the bugtracker at savannah |
- If you think you found a bug make sure it's not already filed in the bugtracker at savannah |
13 |
- If you have a fix put the patch on Savannah. If it's a patch that affects both core and arch specific |
- If you have a fix put the patch on Savannah. If it's a patch that affects both core and arch specific |
14 |
stuff please separate them so that the core can be applied separately while leaving the other patch 'open' |
stuff please separate them so that the core can be applied separately while leaving the other patch 'open' |
20 |
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 |
21 |
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 |
22 |
for reporting a compiler warning fix. |
for reporting a compiler warning fix. |
23 |
|
- Patches should be specific to a single change or to related changes.Do not mix bugfixes with spelling and other |
24 |
|
trivial fixes unless the bugfix is trivial too.Do not reorganize code and rename identifiers in the same patch you |
25 |
|
change behaviour if not necessary.A patch is easier to read and understand if it's to the point and short than |
26 |
|
if it's not to the point and long :) so the chances for it to be applied are greater. |
27 |
|
|
28 |
For platform porters: |
For platform porters: |
29 |
|
|