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>

authored by Willy Tarreau and committed by Linus Torvalds adbd5886 ddb2c435

+46
+46
Documentation/SubmittingPatches
··· 327 now, but you can do this to mark internal company procedures or just 328 point out some special detail about the sign-off. 329 330 331 13) When to use Acked-by: and Cc: 332
··· 327 now, but you can do this to mark internal company procedures or just 328 point out some special detail about the sign-off. 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 + 376 377 13) When to use Acked-by: and Cc: 378