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 Some people also put extra tags at the end.
  57
  58 "Acked-by:" says that the patch was reviewed by the person who
  59 is more familiar with the issues and the area the patch attempts
  60 to modify.  "Tested-by:" says the patch was tested by the person
  61 and found to have the desired effect.
  62
  63 If you are a subsystem or branch maintainer, sometimes you need to slightly
  64 modify patches you receive in order to merge them, because the code is not
  65 exactly the same in your tree and the submitters'. If you stick strictly to
  66 rule (c), you should ask the submitter to rediff, but this is a totally
  67 counter-productive waste of time and energy. Rule (b) allows you to adjust
  68 the code, but then it is very impolite to change one submitter's code and
  69 make him endorse your bugs. To solve this problem, it is recommended that
  70 you add a line between the last Signed-off-by header and yours, indicating
  71 the nature of your changes. While there is nothing mandatory about this, it
  72 seems like prepending the description with your mail and/or name, all
  73 enclosed in square brackets, is noticeable enough to make it obvious that
  74 you are responsible for last-minute changes. Example :
  75
  76         Signed-off-by: Random J Developer <random@developer.example.org>
  77         [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
  78         Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
  79
  80 This practise is particularly helpful if you maintain a stable branch and
  81 want at the same time to credit the author, track changes, merge the fix,
  82 and protect the submitter from complaints. Note that under no circumstances
  83 can you change the author's identity (the From header), as it is the one
  84 which appears in the changelog.
  85
  86 Special note to back-porters: It seems to be a common and useful practise
  87 to insert an indication of the origin of a patch at the top of the commit
  88 message (just after the subject line) to facilitate tracking. For instance,
  89 here's what we see in 2.6-stable :
  90
  91     Date:   Tue May 13 19:10:30 2008 +0000
  92
  93         SCSI: libiscsi regression in 2.6.25: fix nop timer handling
  94
  95         commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
  96
  97 And here's what appears in 2.4 :
  98
  99     Date:   Tue May 13 22:12:27 2008 +0200
 100
 101         wireless, airo: waitbusy() won't delay
 102
 103         [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
 104
 105 Whatever the format, this information provides a valuable help to people
 106 tracking your trees, and to people trying to trouble-shoot bugs in your
 107 tree.