Large HOWTO update, with kernel development section based on Paolo's document

1 files changed, 135 insertions, 6 deletions

diff --git a/HOWTO b/HOWTO
index dad483aa5b12a0..ed9633e967d02f 100644
--- a/HOWTO
+++ b/HOWTO
@@ -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.