diff options
Diffstat (limited to 'Documentation/SubmittingPatches')
| -rw-r--r-- | Documentation/SubmittingPatches | 26 |
1 files changed, 21 insertions, 5 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 0958e97d4bf4..a30dd4480ad4 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -122,11 +122,11 @@ then only post say 15 or so at a time and wait for review and integration. Check your patch for basic style violations, details of which can be found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probabally +the reviewers time and will get your patch rejected, probably without even being read. At a minimum you should check your patches with the patch style -checker prior to submission (scripts/patchcheck.pl). You should +checker prior to submission (scripts/checkpatch.pl). You should be able to justify all violations that remain in your patch. @@ -464,9 +464,25 @@ section Linus Computer Science 101. Nuff said. If your code deviates too much from this, it is likely to be rejected without further review, and without comment. +Once significant exception is when moving code from one file to +another in this case you should not modify the moved code at all in +the same patch which moves it. This clearly delineates the act of +moving the code and your changes. This greatly aids review of the +actual differences and allows tools to better track the history of +the code itself. + Check your patches with the patch style checker prior to submission -(scripts/checkpatch.pl). You should be able to justify all -violations that remain in your patch. +(scripts/checkpatch.pl). The style checker should be viewed as +a guide not as the final word. If your code looks better with +a violation then its probably best left alone. + +The checker reports at three levels: + - ERROR: things that are very likely to be wrong + - WARNING: things requiring careful review + - CHECK: things requiring thought + +You should be able to justify all violations that remain in your +patch. @@ -544,7 +560,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> Kernel Documentation/CodingStyle: - <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> + <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle> Linus Torvalds's mail on the canonical patch format: <http://lkml.org/lkml/2005/4/7/183> |