cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

modifying-patches.rst (2328B)


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