diff options
| author | Greg Kroah-Hartman <gregkh@suse.de> | 2005-11-12 14:06:05 -0800 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@suse.de> | 2005-11-12 14:06:05 -0800 |
| commit | 24b51e05c0d244509adb1c6422ab41c1d5cb34a8 (patch) | |
| tree | bb61b5f9c9504edc992fa9e8637c5c90e054520f /HOWTO | |
| parent | 98068043aaa5758f8daec122688fc338c5a026f1 (diff) | |
| download | patches-24b51e05c0d244509adb1c6422ab41c1d5cb34a8.tar.gz | |
added Randy's comments on the HOWTO file
Diffstat (limited to 'HOWTO')
| -rw-r--r-- | HOWTO | 21 |
1 files changed, 15 insertions, 6 deletions
@@ -64,14 +64,14 @@ their statements on legal matters. Documentation ------------ -The Linux kernel source tree has a huge range of documents that are +The Linux kernel source tree has a large range of documents that are invaluable in learning how to interact with the kernel community. Here is a list of files that are in the kernel source tree that are required reading: Documetation/CodingStyle This describes the Linux kernel coding style, and some of the rationale behind it. The main point here is that we have a coding - style, and you can not ignore it. + style, and you cannot ignore it. Documentation/SubmittingPatches Documentation/SubmittingDrivers @@ -82,9 +82,15 @@ reading: accepted into the main kernel source tree. If you do not follow these rules, the odds of your patch being accepted are very low. + Other excellent descriptions of how to create patches properly are: + "The Perfect Patch" + http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt + "Linux kernel patch submission format" + http://linux.yyz.us/patch-format.html + Documentation/stable_api_nonsense.txt This file describes the rationale behind why the Linux kernel does - not have a stable in-kernel api. If you want to try to come up with + not have a stable in-kernel API. If you want to try to come up with a shim-layer for some subsystem, in order to make it easier to adapt your existing code to Linux, or to try to mitigate the rapid change within the Linux kernel source tree, this document describes why @@ -271,7 +277,9 @@ exactly opposite of what companies are used to doing. Your proposal should also be introduced very early in the development process, so that you can receive feedback on what you are doing. It also lets the community feel that you are working with them, and not simply using them -as a dumping ground for your feature. +as a dumping ground for your feature. However, don't send 50 emails at +one time to a mailing list, your patch series should be smaller than +that almost all of the time. The reasons for breaking things up are the following: @@ -318,8 +326,9 @@ start exactly where you are now. ---------- Thanks to Randy Dunlap and Gerrit Huizenga for the list of things you -should and should not say. Also thanks to Pat Mochel, Hanna Linder, and Kay -Sievers for their review and comments on early drafts of this document. +should and should not say. Also thanks to Pat Mochel, Hanna Linder, +Randy Dunlap, and Kay Sievers for their review and comments on early +drafts of this document. |