|
@@ -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.
|
|
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:
|
|
The canonical patch subject line is:
|
|
|
|
|