diff options
author | Greg Kroah-Hartman <gregkh@suse.de> | 2005-11-15 11:20:39 -0800 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2005-11-15 11:20:39 -0800 |
commit | e0d1d74024639c31e34a22bd76cfa958464a8088 (patch) | |
tree | 5e87660b2025303f607e19164e2a840b2d8f458a /HOWTO | |
parent | 17ce300e15019967a2f594d5529b4e398126c149 (diff) | |
download | patches-e0d1d74024639c31e34a22bd76cfa958464a8088.tar.gz |
Large HOWTO update, with kernel development section based on Paolo's document
Diffstat (limited to 'HOWTO')
-rw-r--r-- | HOWTO | 141 |
1 files changed, 135 insertions, 6 deletions
@@ -188,7 +188,134 @@ mailing list, and can be found at: The development process ----------------------- -<TODO> +Linux kernel development process currently consists of a few different +main kernel "branches" and lots of different subsystem-specific kernel +branches. These different branches are: + - main 2.6.x kernel tree + - 2.6.x.y -stable kernel tree + - 2.6.x -git kernel patches + - 2.6.x -mm kernel patches + - subsystem specific kernel trees and patches + + +2.6.x kernel tree +----------------- + +2.6.x kernels are maintained by Linus Torvalds, and can be found on +kernel.org in the pub/linux/kernel/v2.6/ directory. It's development process +is as follows: + - As soon a new kernel is released a two weeks windows is open, during this + period of time maintainers can submit big diffs to Linus, usually the + patched sited in -mm kernels for a few weeks. The preferred way to submit + big changes is using git (more information about git can be found at + http://git.or.cz/) but plain patches are also just fine. + - After two weeks a -rc1 kernel is released and now is possible to push only + patches that do not include new functionalities that could affect the + stability of the whole kernel. Please note that a whole new driver (or + filesystem) might be accepted after -rc1 because there is no risk of + causing regressions with such a change as long as the change is + self-contained and does not affect areas outside of the code that is being + added. git can be used to send patches to Linus after -rc1 is + released, but the patches need to also be sent to a public mailing + list for review. + - A new -rc is released whenever Linus deems the current git (the + kernel's source management) tree to be in a reasonably sane state + adequate for testing. The goal is to release a new -rc kernel every + week. + - Process continues until the kernel is considered "ready", the + process should last around 6 weeks. + +It is worth to mention what Andrew Morton wrote on the linux-kernel +mailing list about kernel releases: + "Nobody knows when a kernel will be released, because it's + released according to perceived bug status, not according to a + preconceived timeline." + + +2.6.x.y -stable kernel tree +--------------------------- + +Kernels with 4 digit versions are -stable kernels. They contain +relativly small and critical fixes for security problems or significant +regressions discovered in a given 2.6.x kernel. + +This is the recommended branch for users who want the most recent stable +kernel and are not interested in helping test development/experimental +versions. + +If no 2.6.x.y kernel is available, then the highest numbered 2.6.x +kernel is the current stable kernel. + +2.6.x.y are maintained by the "stable" team <stable@kernel.org>, are +released almost every week. + +The file Documentation/stable_kernel_rules.txt in the kernel tree +documents what kinds of changes are acceptable for the -stable tree, and +how the release process works. + + +2.6.x -git patches +------------------ + +These are daily snapshots of Linus' kernel tree which is managed in a +git repository (hence the name.) These patches are usually released +daily and represent the current state of Linus' tree. They are more +experimental than -rc kernels since they are generated automatically +without even a cursory glance to see if they are sane. + +2.6.x -mm kernel patches +------------------------ + +These are experimental kernel patches released by Andrew Morton. Andrew +takes all of the different subsystem kernel trees and patches and mushes +them together, along with a lot of patches that have been plucked from +the linux-kernel mailing list. This tree serves as a proving ground for +new features and patches. Once a patch has proved its worth in -mm for +a while Andrew or the subsystem maintainer pushes it on to Linus for +inclusion in mainline. + +It is heavily encouraged that all new patches get tested in the -mm tree +before they are sent to Linus for inclusion in the main kernel tree. + +These kernels are not appropriate for use on systems that are supposed +to be stable and they are more risky to run than any of the other +branches. + +If you wish to help out with the kernel development process, please test +and use these kernel releases and provide feedback to the linux-kernel +mailing list if you have any problems, and if everything works properly. + +These kernels in addition to all the other experimental patches they +contain usually also contain any changes in the mainline -git kernels +available at the time of release. + +The -mm kernels are not released on a fixed schedule, but usually a few +-mm kernels are released in between each -rc kernel (1 to 3 is common). + +Subsystem Specific kernel trees and patches +------------------------------------------- + +A number of the different kernel subsystem developers expose their +development trees so that others can see what is happening in the +different areas of the kernel. These trees are pulled into the -mm +kernel releases as described above. + +Here is a list of some of the different kernel trees available: + - + + +Bug Reporting +------------- + +bugzilla.kernel.org is where the Linux kernel developers track kernel +bugs. Users are encouraged to report all bugs that they find in this +tool. + +The file REPORTING-BUGS in the main kernel source directory has a good +template for how to report a possible kernel bug, and details what kind +of information is needed by the kernel developers to help track down the +problem. + Mailing lists @@ -417,11 +544,13 @@ 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, -Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees -Cook, Andrew Morton, Andi Kleen, and Alex Shepard for their review and -comments on early drafts of this document. +Thanks to Paolo Ciarrocchi who allowed the "Development Process" section +to be based on text he had written, and to Randy Dunlap and Gerrit +Huizenga for some of the list of things you should and should not say. +Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, +Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi +Kleen, and Alex Shepard for their review and comments on early drafts of +this document. |