diff options
-rw-r--r-- | Documentation/SubmittingPatches | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 9c93a03ea33b..118ca6e9404f 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 | |||
327 | now, but you can do this to mark internal company procedures or just | 327 | now, but you can do this to mark internal company procedures or just |
328 | point out some special detail about the sign-off. | 328 | point out some special detail about the sign-off. |
329 | 329 | ||
330 | If you are a subsystem or branch maintainer, sometimes you need to slightly | ||
331 | modify patches you receive in order to merge them, because the code is not | ||
332 | exactly the same in your tree and the submitters'. If you stick strictly to | ||
333 | rule (c), you should ask the submitter to rediff, but this is a totally | ||
334 | counter-productive waste of time and energy. Rule (b) allows you to adjust | ||
335 | the code, but then it is very impolite to change one submitter's code and | ||
336 | make him endorse your bugs. To solve this problem, it is recommended that | ||
337 | you add a line between the last Signed-off-by header and yours, indicating | ||
338 | the nature of your changes. While there is nothing mandatory about this, it | ||
339 | seems like prepending the description with your mail and/or name, all | ||
340 | enclosed in square brackets, is noticeable enough to make it obvious that | ||
341 | you 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 | |||
347 | This practise is particularly helpful if you maintain a stable branch and | ||
348 | want at the same time to credit the author, track changes, merge the fix, | ||
349 | and protect the submitter from complaints. Note that under no circumstances | ||
350 | can you change the author's identity (the From header), as it is the one | ||
351 | which appears in the changelog. | ||
352 | |||
353 | Special note to back-porters: It seems to be a common and useful practise | ||
354 | to insert an indication of the origin of a patch at the top of the commit | ||
355 | message (just after the subject line) to facilitate tracking. For instance, | ||
356 | here'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 | |||
364 | And 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 | |||
372 | Whatever the format, this information provides a valuable help to people | ||
373 | tracking your trees, and to people trying to trouble-shoot bugs in your | ||
374 | tree. | ||
375 | |||
330 | 376 | ||
331 | 13) When to use Acked-by: and Cc: | 377 | 13) When to use Acked-by: and Cc: |
332 | 378 | ||