-11) Sign your work
-
-To improve tracking of who did what, especially with patches that can
-percolate to their final resting place in the kernel through several
-layers of maintainers, we've introduced a "sign-off" procedure on
-patches that are being emailed around.
-
-The sign-off is a simple line at the end of the explanation for the
-patch, which certifies that you wrote it or otherwise have the right to
-pass it on as an open-source patch. The rules are pretty simple: if you
-can certify the below:
+To improve tracking of who did what, we use the "sign-off" procedure
+introduced by the Linux kernel. The sign-off is a simple line at the
+end of the explanation for the patch, which certifies that you wrote
+it or otherwise have the right to pass it on as an open-source patch.
+The rules are pretty simple: if you can certify the below:
Developer's Certificate of Origin 1.1
Signed-off-by: Random J Developer <random@developer.example.org>
-using your real name (sorry, no pseudonyms or anonymous contributions.)
-This line can be automatically added by git if you run the git-commit
-command with the -s option.
-
-Notice that you can place your own Signed-off-by: line when
-forwarding somebody else's patch with the above rules for
-D-C-O. Indeed you are encouraged to do so. Do not forget to
-place an in-body "From: " line at the beginning to properly attribute
-the change to its true author (see (2) above).
-
-Also notice that a real name is used in the Signed-off-by: line. Please
-don't hide your real name.
+using your real name (sorry, no pseudonyms or anonymous
+contributions). This line can be automatically added by git if you
+run the git-commit command with the -s option.
If you like, you can put extra tags at the end:
You can also create your own tag or use one that's in common usage
such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
-If you are a subsystem or branch maintainer, sometimes you need to slightly
-modify patches you receive in order to merge them, because the code is not
-exactly the same in your tree and the submitters'. If you stick strictly to
-rule (c), you should ask the submitter to rediff, but this is a totally
-counter-productive waste of time and energy. Rule (b) allows you to adjust
-the code, but then it is very impolite to change one submitter's code and
-make him endorse your bugs. To solve this problem, it is recommended that
-you add a line between the last Signed-off-by header and yours, indicating
-the nature of your changes. While there is nothing mandatory about this, it
-seems like prepending the description with your mail and/or name, all
-enclosed in square brackets, is noticeable enough to make it obvious that
-you are responsible for last-minute changes. Example :
+Sometimes you need to slightly modify patches you receive in order to
+merge them, because the code is not exactly the same in your tree and
+the submitters'. If you stick strictly to rule (c), you should ask the
+submitter to rediff, but this is a totally counter-productive waste of
+time and energy. Rule (b) allows you to adjust the code, but then it
+is very impolite to change one submitter's code and make him endorse
+your bugs. To solve this problem, it is recommended that you add a
+line between the last Signed-off-by header and yours, indicating the
+nature of your changes. While there is nothing mandatory about this,
+it seems like prepending the description with your mail and/or name,
+all enclosed in square brackets, is noticeable enough to make it
+obvious that you are responsible for last-minute changes. Example :
Signed-off-by: Random J Developer <random@developer.example.org>
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
-
-This practise is particularly helpful if you maintain a stable branch and
-want at the same time to credit the author, track changes, merge the fix,
-and protect the submitter from complaints. Note that under no circumstances
-can you change the author's identity (the From header), as it is the one
-which appears in the changelog.
-
-Special note to back-porters: It seems to be a common and useful practise
-to insert an indication of the origin of a patch at the top of the commit
-message (just after the subject line) to facilitate tracking. For instance,
-here's what we see in 2.6-stable :
-
- Date: Tue May 13 19:10:30 2008 +0000
-
- SCSI: libiscsi regression in 2.6.25: fix nop timer handling
-
- commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
-
-And here's what appears in 2.4 :
-
- Date: Tue May 13 22:12:27 2008 +0200
-
- wireless, airo: waitbusy() won't delay
-
- [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
-
-Whatever the format, this information provides a valuable help to people
-tracking your trees, and to people trying to trouble-shoot bugs in your
-tree.