[PATCH 2/2] docs: update the development process document.

[Luis de Bethencourt]

From: Luis de Bethencourt <luis@xxxxxxxxxxxxxxxxx>
Date: Sun, 24 Jul 2011 04:03:46 +0200

    Here's a set of changes updating Documentation/development-process.
    I have updated the kernel releases.

Signed-off-by: Luis de Bethencourt <luis@xxxxxxxxxxxxxxxxx>

---
 Documentation/development-process/2.Process |   36 +++++++++++++++------------
 1 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/Documentation/development-process/2.Process
b/Documentation/development-process/2.Process
index 4823577..2d79ddb 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -14,6 +14,7 @@ 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.39	May 18, 2011
 	2.6.38	March 14, 2011
 	2.6.37	January 4, 2011
 	2.6.36	October 20, 2010
@@ -65,19 +66,18 @@ 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.38 development cycle went (all dates in
+As an example, here is how the 2.6.39 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
+	March 29	2.6.39-rc1, merge window closes
+	April 6		2.6.39-rc2
+	April 12	2.6.39-rc3
+	April 19	2.6.39-rc4
+	April 27	2.6.39-rc5
+	May 4		2.6.39-rc6
+	May 10		2.6.39-rc7
+	May 18		2.6.39 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
@@ -103,13 +103,17 @@ 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:
+for example, the 2.6.38 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
+	March 14	2.6.38 stable release
+	March 23	2.6.38.1
+	March 27	2.6.38.2
+	April 14	2.6.38.3
+	April 21	2.6.38.4
+	May 2		2.6.38.5
+	May 9		2.6.38.6
+	May 21		2.6.38.7
+	June 3		2.6.38.8

 2.6.36.4 was the final stable update for the 2.6.36 release.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/