docs: update the development process document

Here's a set of changes updating Documentation/development-process.  I have
update kernel releases and relevant statistics, added information for a
couple of tools, zapped some trailing white space, and generally tried to
make it more closely match the current state of affairs.

[Typo fixes from Joe Perches and Nicolas Kaiser incorporated]

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Greg KH <greg@kroah.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>

1 files changed, 88 insertions, 89 deletions

diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
index 911a45186340..4823577c6509 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -14,16 +14,15 @@ The kernel developers use a loosely time-based release process, with a new
 major kernel release happening every two or three months.  The recent
 release history looks like this:
 
-        2.6.26  July 13, 2008
-        2.6.25  April 16, 2008
-        2.6.24  January 24, 2008
-        2.6.23  October 9, 2007
-        2.6.22  July 8, 2007
-        2.6.21  April 25, 2007
-        2.6.20  February 4, 2007
+        2.6.38  March 14, 2011
+        2.6.37  January 4, 2011
+        2.6.36  October 20, 2010
+        2.6.35  August 1, 2010
+        2.6.34  May 15, 2010
+        2.6.33  February 24, 2010
 
 Every 2.6.x release is a major kernel release with new features, internal
-API changes, and more.  A typical 2.6 release can contain over 10,000
+API changes, and more.  A typical 2.6 release can contain nearly 10,000
 changesets with changes to several hundred thousand lines of code.  2.6 is
 thus the leading edge of Linux kernel development; the kernel uses a
 rolling development model which is continually integrating major changes.
@@ -42,13 +41,13 @@ merge window do not come out of thin air; they have been collected, tested,
 and staged ahead of time.  How that process works will be described in
 detail later on).
 
-The merge window lasts for two weeks.  At the end of this time, Linus
-Torvalds will declare that the window is closed and release the first of
-the "rc" kernels.  For the kernel which is destined to be 2.6.26, for
-example, the release which happens at the end of the merge window will be
-called 2.6.26-rc1.  The -rc1 release is the signal that the time to merge
-new features has passed, and that the time to stabilize the next kernel has
-begun.
+The merge window lasts for approximately two weeks.  At the end of this
+time, Linus Torvalds will declare that the window is closed and release the
+first of the "rc" kernels.  For the kernel which is destined to be 2.6.40,
+for example, the release which happens at the end of the merge window will
+be called 2.6.40-rc1.  The -rc1 release is the signal that the time to
+merge new features has passed, and that the time to stabilize the next
+kernel has begun.
 
 Over the next six to ten weeks, only patches which fix problems should be
 submitted to the mainline.  On occasion a more significant change will be
@@ -66,20 +65,19 @@ will get up to somewhere between -rc6 and -rc9 before the kernel is
 considered to be sufficiently stable and the final 2.6.x release is made.
 At that point the whole process starts over again.
 
-As an example, here is how the 2.6.25 development cycle went (all dates in
-2008): 
-
-        January 24      2.6.24 stable release
-        February 10     2.6.25-rc1, merge window closes
-        February 15     2.6.25-rc2
-        February 24     2.6.25-rc3
-        March 4         2.6.25-rc4
-        March 9         2.6.25-rc5
-        March 16        2.6.25-rc6
-        March 25        2.6.25-rc7
-        April 1         2.6.25-rc8
-        April 11        2.6.25-rc9
-        April 16        2.6.25 stable release
+As an example, here is how the 2.6.38 development cycle went (all dates in
+2011):
+
+        January 4       2.6.37 stable release
+        January 18      2.6.38-rc1, merge window closes
+        January 21      2.6.38-rc2
+        February 1      2.6.38-rc3
+        February 7      2.6.38-rc4
+        February 15     2.6.38-rc5
+        February 21     2.6.38-rc6
+        March 1         2.6.38-rc7
+        March 7         2.6.38-rc8
+        March 14        2.6.38 stable release
 
 How do the developers decide when to close the development cycle and create
 the stable release?  The most significant metric used is the list of
@@ -87,7 +85,7 @@ regressions from previous releases.  No bugs are welcome, but those which
 break systems which worked in the past are considered to be especially
 serious.  For this reason, patches which cause regressions are looked upon
 unfavorably and are quite likely to be reverted during the stabilization
-period. 
+period.
 
 The developers' goal is to fix all known regressions before the stable
 release is made.  In the real world, this kind of perfection is hard to
@@ -99,26 +97,34 @@ kernels go out with a handful of known regressions though, hopefully, none
 of them are serious.
 
 Once a stable release is made, its ongoing maintenance is passed off to the
-"stable team," currently comprised of Greg Kroah-Hartman and Chris Wright.
-The stable team will release occasional updates to the stable release using
-the 2.6.x.y numbering scheme.  To be considered for an update release, a
-patch must (1) fix a significant bug, and (2) already be merged into the
-mainline for the next development kernel.  Continuing our 2.6.25 example,
-the history (as of this writing) is:
-
-        May 1           2.6.25.1
-        May 6           2.6.25.2 
-        May 9           2.6.25.3 
-        May 15          2.6.25.4
-        June 7          2.6.25.5
-        June 9          2.6.25.6
-        June 16         2.6.25.7
-        June 21         2.6.25.8
-        June 24         2.6.25.9
-
-Stable updates for a given kernel are made for approximately six months;
-after that, the maintenance of stable releases is solely the responsibility
-of the distributors which have shipped that particular kernel.
+"stable team," currently consisting of Greg Kroah-Hartman.  The stable team
+will release occasional updates to the stable release using the 2.6.x.y
+numbering scheme.  To be considered for an update release, a patch must (1)
+fix a significant bug, and (2) already be merged into the mainline for the
+next development kernel.  Kernels will typically receive stable updates for
+a little more than one development cycle past their initial release.  So,
+for example, the 2.6.36 kernel's history looked like:
+
+        October 10      2.6.36 stable release
+        November 22     2.6.36.1
+        December 9      2.6.36.2
+        January 7       2.6.36.3
+        February 17     2.6.36.4
+
+2.6.36.4 was the final stable update for the 2.6.36 release.
+
+Some kernels are designated "long term" kernels; they will receive support
+for a longer period.  As of this writing, the current long term kernels
+and their maintainers are:
+
+        2.6.27  Willy Tarreau           (Deep-frozen stable kernel)
+        2.6.32  Greg Kroah-Hartman
+        2.6.35  Andi Kleen              (Embedded flag kernel)
+
+The selection of a kernel for long-term support is purely a matter of a
+maintainer having the need and the time to maintain that release.  There
+are no known plans for long-term support for any specific upcoming
+release.
 
 
 2.2: THE LIFECYCLE OF A PATCH
@@ -130,7 +136,7 @@ each patch implements a change which is desirable to have in the mainline.
 This process can happen quickly for minor fixes, or, in the case of large
 and controversial changes, go on for years.  Much developer frustration
 comes from a lack of understanding of this process or from attempts to
-circumvent it.  
+circumvent it.
 
 In the hopes of reducing that frustration, this document will describe how
 a patch gets into the kernel.  What follows below is an introduction which
@@ -193,8 +199,8 @@ involved.
 2.3: HOW PATCHES GET INTO THE KERNEL
 
 There is exactly one person who can merge patches into the mainline kernel
-repository: Linus Torvalds.  But, of the over 12,000 patches which went
-into the 2.6.25 kernel, only 250 (around 2%) were directly chosen by Linus
+repository: Linus Torvalds.  But, of the over 9,500 patches which went
+into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus
 himself.  The kernel project has long since grown to a size where no single
 developer could possibly inspect and select every patch unassisted.  The