X-Git-Url: http://git.rot13.org/?a=blobdiff_plain;f=Documentation%2FSubmittingPatches;h=c2c85bcb3d438b983ccc1535acbbd185867e26c3;hb=f8a88b19b9d4f59bd625b4852c1b1138a5cf89f3;hp=237d54c44bc5ee504dc57f8d5f65edc389081e04;hpb=b6ec995a21a9428aef620b5adf46d047a18d88b8;p=powerpc.git diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 237d54c44b..c2c85bcb3d 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -78,7 +78,9 @@ Randy Dunlap's patch scripts: http://www.xenotime.net/linux/scripts/patching-scripts-002.tar.gz Andrew Morton's patch scripts: -http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.20 +http://www.zip.com.au/~akpm/linux/patches/ +Instead of these scripts, quilt is the recommended patch management +tool (see above). @@ -97,7 +99,7 @@ need to split up your patch. See #3, next. 3) Separate your changes. -Separate each logical change into its own patch. +Separate _logical changes_ into a single patch file. For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two @@ -112,6 +114,10 @@ If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description. +If you cannot condense your patch set into a smaller set of patches, +then only post say 15 or so at a time and wait for review and integration. + + 4) Select e-mail destination. @@ -124,6 +130,10 @@ your patch to the primary Linux kernel developer's mailing list, linux-kernel@vger.kernel.org. Most kernel developers monitor this e-mail list, and can comment on your changes. + +Do not send more than 15 patches at once to the vger mailing lists!!! + + Linus Torvalds is the final arbiter of all changes accepted into the Linux kernel. His e-mail address is . He gets a lot of e-mail, so typically you should do your best to -avoid- sending @@ -149,6 +159,9 @@ USB, framebuffer devices, the VFS, the SCSI subsystem, etc. See the MAINTAINERS file for a mailing list that relates specifically to your change. +Majordomo lists of VGER.KERNEL.ORG at: + + If changes affect userland-kernel interfaces, please send the MAN-PAGES maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at least a notification of the change, @@ -158,7 +171,7 @@ Even if the maintainer did not respond in step #4, make sure to ALWAYS copy the maintainer when you change their code. For small patches you may want to CC the Trivial Patch Monkey -trivial@rustcorp.com.au set up by Rusty Russell; which collects "trivial" +trivial@kernel.org managed by Adrian Bunk; which collects "trivial" patches. Trivial patches must qualify for one of the following rules: Spelling fixes in documentation Spelling fixes which could break grep(1). @@ -171,7 +184,7 @@ patches. Trivial patches must qualify for one of the following rules: since people copy, as long as it's trivial) Any fix by the author/maintainer of the file. (ie. patch monkey in re-transmission mode) -URL: +URL: @@ -373,27 +386,14 @@ a diffstat, to show what files have changed, and the number of inserted and deleted lines per file. A diffstat is especially useful on bigger patches. Other comments relevant only to the moment or the maintainer, not suitable for the permanent changelog, should also go here. +Use diffstat options "-p 1 -w 70" so that filenames are listed from the +top of the kernel source tree and don't use too much horizontal space +(easily fit in 80 columns, maybe with some indentation). See more details on the proper patch format in the following references. -13) More references for submitting patches - -Andrew Morton, "The perfect patch" (tpp). - - -Jeff Garzik, "Linux kernel patch submission format." - - -Greg KH, "How to piss off a kernel subsystem maintainer" - - -Kernel Documentation/CodingStyle - - -Linus Torvald's mail on the canonical patch format: - ----------------------------------- @@ -466,3 +466,31 @@ and 'extern __inline__'. Don't try to anticipate nebulous future cases which may or may not be useful: "Make it as simple as you can, and no simpler." + + +---------------------- +SECTION 3 - REFERENCES +---------------------- + +Andrew Morton, "The perfect patch" (tpp). + + +Jeff Garzik, "Linux kernel patch submission format." + + +Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer". + + + + + +NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!. + + +Kernel Documentation/CodingStyle + + +Linus Torvald's mail on the canonical patch format: + +-- +Last updated on 17 Nov 2005.