diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2008-04-11 16:24:16 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-04-11 16:24:16 -0400 |
commit | 14897e35fdc045fff9baabf0354570da22386706 (patch) | |
tree | 32cf1fcd7696e2018a05f2e4f8d5d20166af21ab /Documentation/SubmittingPatches | |
parent | b0fac02370cffad956ff3de5e8ed4df7e7b875d7 (diff) | |
parent | 14dadf1d5eb5bea2dd115852cfee880505c1c169 (diff) |
Merge branch 'docs' of git://git.lwn.net/linux-2.6
* 'docs' of git://git.lwn.net/linux-2.6:
Add additional examples in Documentation/spinlocks.txt
Move sched-rt-group.txt to scheduler/
Documentation: move rpc-cache.txt to filesystems/
Documentation: move nfsroot.txt to filesystems/
Spell out behavior of atomic_dec_and_lock() in kerneldoc
Fix a typo in highres.txt
Fixes to the seq_file document
Fill out information on patch tags in SubmittingPatches
Add the seq_file documentation
Diffstat (limited to 'Documentation/SubmittingPatches')
-rw-r--r-- | Documentation/SubmittingPatches | 54 |
1 files changed, 51 insertions, 3 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 47a539c7642d..1fc4e7144dce 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
@@ -328,7 +328,7 @@ 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 | 330 | ||
331 | 13) When to use Acked-by: | 331 | 13) When to use Acked-by: and Cc: |
332 | 332 | ||
333 | The Signed-off-by: tag indicates that the signer was involved in the | 333 | The Signed-off-by: tag indicates that the signer was involved in the |
334 | development of the patch, or that he/she was in the patch's delivery path. | 334 | development of the patch, or that he/she was in the patch's delivery path. |
@@ -349,11 +349,59 @@ Acked-by: does not necessarily indicate acknowledgement of the entire patch. | |||
349 | For example, if a patch affects multiple subsystems and has an Acked-by: from | 349 | For example, if a patch affects multiple subsystems and has an Acked-by: from |
350 | one subsystem maintainer then this usually indicates acknowledgement of just | 350 | one subsystem maintainer then this usually indicates acknowledgement of just |
351 | the part which affects that maintainer's code. Judgement should be used here. | 351 | the part which affects that maintainer's code. Judgement should be used here. |
352 | When in doubt people should refer to the original discussion in the mailing | 352 | When in doubt people should refer to the original discussion in the mailing |
353 | list archives. | 353 | list archives. |
354 | 354 | ||
355 | If a person has had the opportunity to comment on a patch, but has not | ||
356 | provided such comments, you may optionally add a "Cc:" tag to the patch. | ||
357 | This is the only tag which might be added without an explicit action by the | ||
358 | person it names. This tag documents that potentially interested parties | ||
359 | have been included in the discussion | ||
355 | 360 | ||
356 | 14) The canonical patch format | 361 | |
362 | 14) Using Test-by: and Reviewed-by: | ||
363 | |||
364 | A Tested-by: tag indicates that the patch has been successfully tested (in | ||
365 | some environment) by the person named. This tag informs maintainers that | ||
366 | some testing has been performed, provides a means to locate testers for | ||
367 | future patches, and ensures credit for the testers. | ||
368 | |||
369 | Reviewed-by:, instead, indicates that the patch has been reviewed and found | ||
370 | acceptable according to the Reviewer's Statement: | ||
371 | |||
372 | Reviewer's statement of oversight | ||
373 | |||
374 | By offering my Reviewed-by: tag, I state that: | ||
375 | |||
376 | (a) I have carried out a technical review of this patch to | ||
377 | evaluate its appropriateness and readiness for inclusion into | ||
378 | the mainline kernel. | ||
379 | |||
380 | (b) Any problems, concerns, or questions relating to the patch | ||
381 | have been communicated back to the submitter. I am satisfied | ||
382 | with the submitter's response to my comments. | ||
383 | |||
384 | (c) While there may be things that could be improved with this | ||
385 | submission, I believe that it is, at this time, (1) a | ||
386 | worthwhile modification to the kernel, and (2) free of known | ||
387 | issues which would argue against its inclusion. | ||
388 | |||
389 | (d) While I have reviewed the patch and believe it to be sound, I | ||
390 | do not (unless explicitly stated elsewhere) make any | ||
391 | warranties or guarantees that it will achieve its stated | ||
392 | purpose or function properly in any given situation. | ||
393 | |||
394 | A Reviewed-by tag is a statement of opinion that the patch is an | ||
395 | appropriate modification of the kernel without any remaining serious | ||
396 | technical issues. Any interested reviewer (who has done the work) can | ||
397 | offer a Reviewed-by tag for a patch. This tag serves to give credit to | ||
398 | reviewers and to inform maintainers of the degree of review which has been | ||
399 | done on the patch. Reviewed-by: tags, when supplied by reviewers known to | ||
400 | understand the subject area and to perform thorough reviews, will normally | ||
401 | increase the liklihood of your patch getting into the kernel. | ||
402 | |||
403 | |||
404 | 15) The canonical patch format | ||
357 | 405 | ||
358 | The canonical patch subject line is: | 406 | The canonical patch subject line is: |
359 | 407 | ||