Documentation/SubmittingPatches

   1 11) Sign your work
   2
   3 To improve tracking of who did what, especially with patches that can
   4 percolate to their final resting place in the kernel through several
   5 layers of maintainers, we've introduced a "sign-off" procedure on
   6 patches that are being emailed around.
   7
   8 The sign-off is a simple line at the end of the explanation for the
   9 patch, which certifies that you wrote it or otherwise have the right to
  10 pass it on as an open-source patch.  The rules are pretty simple: if you
  11 can certify the below:
  12
  13         Developer's Certificate of Origin 1.1
  14
  15         By making a contribution to this project, I certify that:
  16
  17         (a) The contribution was created in whole or in part by me and I
  18             have the right to submit it under the open source license
  19             indicated in the file; or
  20
  21         (b) The contribution is based upon previous work that, to the best
  22             of my knowledge, is covered under an appropriate open source
  23             license and I have the right under that license to submit that
  24             work with modifications, whether created in whole or in part
  25             by me, under the same open source license (unless I am
  26             permitted to submit under a different license), as indicated
  27             in the file; or
  28
  29         (c) The contribution was provided directly to me by some other
  30             person who certified (a), (b) or (c) and I have not modified
  31             it.
  32
  33         (d) I understand and agree that this project and the contribution
  34             are public and that a record of the contribution (including all
  35             personal information I submit with it, including my sign-off) is
  36             maintained indefinitely and may be redistributed consistent with
  37             this project or the open source license(s) involved.
  38
  39 then you just add a line saying
  40
  41         Signed-off-by: Random J Developer <random@developer.example.org>
  42
  43 using your real name (sorry, no pseudonyms or anonymous contributions.)
  44 This line can be automatically added by git if you run the git-commit
  45 command with the -s option.
  46
  47 Notice that you can place your own Signed-off-by: line when
  48 forwarding somebody else's patch with the above rules for
  49 D-C-O.  Indeed you are encouraged to do so.  Do not forget to
  50 place an in-body "From: " line at the beginning to properly attribute
  51 the change to its true author (see (2) above).
  52
  53 Also notice that a real name is used in the Signed-off-by: line. Please
  54 don't hide your real name.
  55
  56 If you like, you can put extra tags at the end:
  57
  58 1. "Reported-by:" is used to to credit someone who found the bug that
  59    the patch attempts to fix.
  60 2. "Acked-by:" says that the person who is more familiar with the area
  61    the patch attempts to modify liked the patch.
  62 3. "Reviewed-by:", unlike the other tags, can only be offered by the
  63    reviewer and means that she is completely satisfied that the patch
  64    is ready for application.  It is usually offered only after a
  65    detailed review.
  66 4. "Tested-by:" is used to indicate that the person applied the patch
  67    and found it to have the desired effect.
  68
  69 You can also create your own tag or use one that's in common usage
  70 such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
  71
  72 If you are a subsystem or branch maintainer, sometimes you need to slightly
  73 modify patches you receive in order to merge them, because the code is not
  74 exactly the same in your tree and the submitters'. If you stick strictly to
  75 rule (c), you should ask the submitter to rediff, but this is a totally
  76 counter-productive waste of time and energy. Rule (b) allows you to adjust
  77 the code, but then it is very impolite to change one submitter's code and
  78 make him endorse your bugs. To solve this problem, it is recommended that
  79 you add a line between the last Signed-off-by header and yours, indicating
  80 the nature of your changes. While there is nothing mandatory about this, it
  81 seems like prepending the description with your mail and/or name, all
  82 enclosed in square brackets, is noticeable enough to make it obvious that
  83 you are responsible for last-minute changes. Example :
  84
  85         Signed-off-by: Random J Developer <random@developer.example.org>
  86         [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
  87         Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
  88
  89 This practise is particularly helpful if you maintain a stable branch and
  90 want at the same time to credit the author, track changes, merge the fix,
  91 and protect the submitter from complaints. Note that under no circumstances
  92 can you change the author's identity (the From header), as it is the one
  93 which appears in the changelog.
  94
  95 Special note to back-porters: It seems to be a common and useful practise
  96 to insert an indication of the origin of a patch at the top of the commit
  97 message (just after the subject line) to facilitate tracking. For instance,
  98 here's what we see in 2.6-stable :
  99
 100     Date:   Tue May 13 19:10:30 2008 +0000
 101
 102         SCSI: libiscsi regression in 2.6.25: fix nop timer handling
 103
 104         commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
 105
 106 And here's what appears in 2.4 :
 107
 108     Date:   Tue May 13 22:12:27 2008 +0200
 109
 110         wireless, airo: waitbusy() won't delay
 111
 112         [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
 113
 114 Whatever the format, this information provides a valuable help to people
 115 tracking your trees, and to people trying to trouble-shoot bugs in your
 116 tree.