1*4ebdf7beSDrew DeVault.. _modifyingpatches: 2*4ebdf7beSDrew DeVault 3*4ebdf7beSDrew DeVaultModifying Patches 4*4ebdf7beSDrew DeVault================= 5*4ebdf7beSDrew DeVault 6*4ebdf7beSDrew DeVaultIf you are a subsystem or branch maintainer, sometimes you need to slightly 7*4ebdf7beSDrew DeVaultmodify patches you receive in order to merge them, because the code is not 8*4ebdf7beSDrew DeVaultexactly the same in your tree and the submitters'. If you stick strictly to 9*4ebdf7beSDrew DeVaultrule (c) of the developers certificate of origin, you should ask the submitter 10*4ebdf7beSDrew DeVaultto rediff, but this is a totally counter-productive waste of time and energy. 11*4ebdf7beSDrew DeVaultRule (b) allows you to adjust the code, but then it is very impolite to change 12*4ebdf7beSDrew DeVaultone submitters code and make him endorse your bugs. To solve this problem, it 13*4ebdf7beSDrew DeVaultis recommended that you add a line between the last Signed-off-by header and 14*4ebdf7beSDrew DeVaultyours, indicating the nature of your changes. While there is nothing mandatory 15*4ebdf7beSDrew DeVaultabout this, it seems like prepending the description with your mail and/or 16*4ebdf7beSDrew DeVaultname, all enclosed in square brackets, is noticeable enough to make it obvious 17*4ebdf7beSDrew DeVaultthat you are responsible for last-minute changes. Example:: 18*4ebdf7beSDrew DeVault 19*4ebdf7beSDrew DeVault Signed-off-by: Random J Developer <random@developer.example.org> 20*4ebdf7beSDrew DeVault [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] 21*4ebdf7beSDrew DeVault Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org> 22*4ebdf7beSDrew DeVault 23*4ebdf7beSDrew DeVaultThis practice is particularly helpful if you maintain a stable branch and 24*4ebdf7beSDrew DeVaultwant at the same time to credit the author, track changes, merge the fix, 25*4ebdf7beSDrew DeVaultand protect the submitter from complaints. Note that under no circumstances 26*4ebdf7beSDrew DeVaultcan you change the author's identity (the From header), as it is the one 27*4ebdf7beSDrew DeVaultwhich appears in the changelog. 28*4ebdf7beSDrew DeVault 29*4ebdf7beSDrew DeVaultSpecial note to back-porters: It seems to be a common and useful practice 30*4ebdf7beSDrew DeVaultto insert an indication of the origin of a patch at the top of the commit 31*4ebdf7beSDrew DeVaultmessage (just after the subject line) to facilitate tracking. For instance, 32*4ebdf7beSDrew DeVaulthere's what we see in a 3.x-stable release:: 33*4ebdf7beSDrew DeVault 34*4ebdf7beSDrew DeVault Date: Tue Oct 7 07:26:38 2014 -0400 35*4ebdf7beSDrew DeVault 36*4ebdf7beSDrew DeVault libata: Un-break ATA blacklist 37*4ebdf7beSDrew DeVault 38*4ebdf7beSDrew DeVault commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream. 39*4ebdf7beSDrew DeVault 40*4ebdf7beSDrew DeVaultAnd here's what might appear in an older kernel once a patch is backported:: 41*4ebdf7beSDrew DeVault 42*4ebdf7beSDrew DeVault Date: Tue May 13 22:12:27 2008 +0200 43*4ebdf7beSDrew DeVault 44*4ebdf7beSDrew DeVault wireless, airo: waitbusy() won't delay 45*4ebdf7beSDrew DeVault 46*4ebdf7beSDrew DeVault [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a] 47*4ebdf7beSDrew DeVault 48*4ebdf7beSDrew DeVaultWhatever the format, this information provides a valuable help to people 49*4ebdf7beSDrew DeVaulttracking your trees, and to people trying to troubleshoot bugs in your 50*4ebdf7beSDrew DeVaulttree. 51