X-Git-Url: http://pileus.org/git/?a=blobdiff_plain;ds=sidebyside;f=Documentation%2FSubmittingPatches;h=397575880dc402d4e3330184b7d55277a94adb8e;hb=c811ac5366750568b0f412c95c6074dec20c69b2;hp=d91125ab6f49253fece7bc6e056cd248ec7812ec;hpb=c8d8170feb824875baf68f8aaecb181a6500ce81;p=~andy%2Flinux diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index d91125ab6f4..397575880dc 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -122,7 +122,7 @@ 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 @@ -340,8 +340,32 @@ now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. +13) When to use Acked-by: -13) The canonical patch format +The Signed-off-by: tag indicates that the signer was involved in the +development of the patch, or that he/she was in the patch's delivery path. + +If a person was not directly involved in the preparation or handling of a +patch but wishes to signify and record their approval of it then they can +arrange to have an Acked-by: line added to the patch's changelog. + +Acked-by: is often used by the maintainer of the affected code when that +maintainer neither contributed to nor forwarded the patch. + +Acked-by: is not as formal as Signed-off-by:. It is a record that the acker +has at least reviewed the patch and has indicated acceptance. Hence patch +mergers will sometimes manually convert an acker's "yep, looks good to me" +into an Acked-by:. + +Acked-by: does not necessarily indicate acknowledgement of the entire patch. +For example, if a patch affects multiple subsystems and has an Acked-by: from +one subsystem maintainer then this usually indicates acknowledgement of just +the part which affects that maintainer's code. Judgement should be used here. + When in doubt people should refer to the original discussion in the mailing +list archives. + + +14) The canonical patch format The canonical patch subject line is: @@ -440,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. @@ -520,7 +560,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! Kernel Documentation/CodingStyle: - + Linus Torvalds's mail on the canonical patch format: