|
|
|
|
@ -46,11 +46,7 @@ features of Savannah help us not lose users' input.
|
|
|
|
|
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 |
|
|
|
|
5. 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. |
|
|
|
|
|