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 | ||
