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