aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/SubmittingPatches
diff options
context:
space:
mode:
authorWilly Tarreau <w@1wt.eu>2008-06-02 18:20:28 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2008-06-05 17:25:24 -0400
commitadbd5886da5f467148b26cca3728ab0e672b3fcc (patch)
treefebe1e9a489267eb03a10b50b2b01d6d656c4715 /Documentation/SubmittingPatches
parentddb2c43594f22843e9f3153da151deaba1a834c5 (diff)
doc: add suggestions about good practises for maintainers
Suggest how to deal with patch modifications caused by merging or back-porting when you're a maintainer. Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/SubmittingPatches')
-rw-r--r--Documentation/SubmittingPatches46
1 files changed, 46 insertions, 0 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 9c93a03ea33..118ca6e9404 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -327,6 +327,52 @@ Some people also put extra tags at the end. They'll just be ignored for
327now, but you can do this to mark internal company procedures or just 327now, but you can do this to mark internal company procedures or just
328point out some special detail about the sign-off. 328point out some special detail about the sign-off.
329 329
330If you are a subsystem or branch maintainer, sometimes you need to slightly
331modify patches you receive in order to merge them, because the code is not
332exactly the same in your tree and the submitters'. If you stick strictly to
333rule (c), you should ask the submitter to rediff, but this is a totally
334counter-productive waste of time and energy. Rule (b) allows you to adjust
335the code, but then it is very impolite to change one submitter's code and
336make him endorse your bugs. To solve this problem, it is recommended that
337you add a line between the last Signed-off-by header and yours, indicating
338the nature of your changes. While there is nothing mandatory about this, it
339seems like prepending the description with your mail and/or name, all
340enclosed in square brackets, is noticeable enough to make it obvious that
341you are responsible for last-minute changes. Example :
342
343 Signed-off-by: Random J Developer <random@developer.example.org>
344 [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
345 Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
346
347This practise is particularly helpful if you maintain a stable branch and
348want at the same time to credit the author, track changes, merge the fix,
349and protect the submitter from complaints. Note that under no circumstances
350can you change the author's identity (the From header), as it is the one
351which appears in the changelog.
352
353Special note to back-porters: It seems to be a common and useful practise
354to insert an indication of the origin of a patch at the top of the commit
355message (just after the subject line) to facilitate tracking. For instance,
356here's what we see in 2.6-stable :
357
358 Date: Tue May 13 19:10:30 2008 +0000
359
360 SCSI: libiscsi regression in 2.6.25: fix nop timer handling
361
362 commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
363
364And here's what appears in 2.4 :
365
366 Date: Tue May 13 22:12:27 2008 +0200
367
368 wireless, airo: waitbusy() won't delay
369
370 [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
371
372Whatever the format, this information provides a valuable help to people
373tracking your trees, and to people trying to trouble-shoot bugs in your
374tree.
375
330 376
33113) When to use Acked-by: and Cc: 37713) When to use Acked-by: and Cc:
332 378