18c2ecf20Sopenharmony_ci.. _modifyingpatches:
28c2ecf20Sopenharmony_ci
38c2ecf20Sopenharmony_ciModifying Patches
48c2ecf20Sopenharmony_ci=================
58c2ecf20Sopenharmony_ci
68c2ecf20Sopenharmony_ciIf you are a subsystem or branch maintainer, sometimes you need to slightly
78c2ecf20Sopenharmony_cimodify patches you receive in order to merge them, because the code is not
88c2ecf20Sopenharmony_ciexactly the same in your tree and the submitters'. If you stick strictly to
98c2ecf20Sopenharmony_cirule (c) of the developers certificate of origin, you should ask the submitter
108c2ecf20Sopenharmony_cito rediff, but this is a totally counter-productive waste of time and energy.
118c2ecf20Sopenharmony_ciRule (b) allows you to adjust the code, but then it is very impolite to change
128c2ecf20Sopenharmony_cione submitters code and make him endorse your bugs. To solve this problem, it
138c2ecf20Sopenharmony_ciis recommended that you add a line between the last Signed-off-by header and
148c2ecf20Sopenharmony_ciyours, indicating the nature of your changes. While there is nothing mandatory
158c2ecf20Sopenharmony_ciabout this, it seems like prepending the description with your mail and/or
168c2ecf20Sopenharmony_ciname, all enclosed in square brackets, is noticeable enough to make it obvious
178c2ecf20Sopenharmony_cithat you are responsible for last-minute changes. Example::
188c2ecf20Sopenharmony_ci
198c2ecf20Sopenharmony_ci       Signed-off-by: Random J Developer <random@developer.example.org>
208c2ecf20Sopenharmony_ci       [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
218c2ecf20Sopenharmony_ci       Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
228c2ecf20Sopenharmony_ci
238c2ecf20Sopenharmony_ciThis practice is particularly helpful if you maintain a stable branch and
248c2ecf20Sopenharmony_ciwant at the same time to credit the author, track changes, merge the fix,
258c2ecf20Sopenharmony_ciand protect the submitter from complaints. Note that under no circumstances
268c2ecf20Sopenharmony_cican you change the author's identity (the From header), as it is the one
278c2ecf20Sopenharmony_ciwhich appears in the changelog.
288c2ecf20Sopenharmony_ci
298c2ecf20Sopenharmony_ciSpecial note to back-porters: It seems to be a common and useful practice
308c2ecf20Sopenharmony_cito insert an indication of the origin of a patch at the top of the commit
318c2ecf20Sopenharmony_cimessage (just after the subject line) to facilitate tracking. For instance,
328c2ecf20Sopenharmony_cihere's what we see in a 3.x-stable release::
338c2ecf20Sopenharmony_ci
348c2ecf20Sopenharmony_ci  Date:   Tue Oct 7 07:26:38 2014 -0400
358c2ecf20Sopenharmony_ci
368c2ecf20Sopenharmony_ci    libata: Un-break ATA blacklist
378c2ecf20Sopenharmony_ci
388c2ecf20Sopenharmony_ci    commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.
398c2ecf20Sopenharmony_ci
408c2ecf20Sopenharmony_ciAnd here's what might appear in an older kernel once a patch is backported::
418c2ecf20Sopenharmony_ci
428c2ecf20Sopenharmony_ci    Date:   Tue May 13 22:12:27 2008 +0200
438c2ecf20Sopenharmony_ci
448c2ecf20Sopenharmony_ci        wireless, airo: waitbusy() won't delay
458c2ecf20Sopenharmony_ci
468c2ecf20Sopenharmony_ci        [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
478c2ecf20Sopenharmony_ci
488c2ecf20Sopenharmony_ciWhatever the format, this information provides a valuable help to people
498c2ecf20Sopenharmony_citracking your trees, and to people trying to troubleshoot bugs in your
508c2ecf20Sopenharmony_citree.
51