Date:	Mon, 15 Jul 2013 19:34:44 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Rob Landley <rob@...dley.net>
CC:	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Willy Tarreau <w@....eu>, Ben Hutchings <ben@...adent.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: [PATCH] Documentation: update references to v2.6.x in development-process

The last mainline release of a v2.6.x kernel was back in May 2011.
Here we update references to be 3.x based, which also means updating
some dates and statistics.

Also update information pertaining to longterm releases.  Here I have
intentionally left out any mention of the v2.6.34.x longterm, since I
will EOL it before this patch makes it in the v3.12 kernel anyway.

Finally, update the links to mmotm and linux-next trees, as neither of
them worked and pre-dated the kernel.org server rebuilds.

Cc: Rob Landley <rob@...dley.net>
Cc: Willy Tarreau <w@....eu>
Cc: Ben Hutchings <ben@...adent.org.uk>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>
Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>

diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
index 4823577..0c943a1 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -14,16 +14,16 @@ 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.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 nearly 10,000
-changesets with changes to several hundred thousand lines of code.  2.6 is
+	3.10	June 30, 2013
+	3.9	April 28, 2013
+	3.8	February 18, 2013
+	3.7	December 10, 2012
+	3.6	September 30, 2012
+	3.5	July 21, 2012
+
+Every 3.x release is a major kernel release with new features, internal
+API changes, and more.  A typical 3.x release can contain over 10,000
+changesets with changes to several hundred thousand lines of code.  3.x is
 thus the leading edge of Linux kernel development; the kernel uses a
 rolling development model which is continually integrating major changes.
 
@@ -43,9 +43,9 @@ detail later on).
 
 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,
+first of the "rc" kernels.  For the kernel which is destined to be 3.12,
 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
+be tagged v3.12-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.
 
@@ -62,22 +62,21 @@ add at any time).
 As fixes make their way into the mainline, the patch rate will slow over
 time.  Linus releases new -rc kernels about once a week; a normal series
 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.
+considered to be sufficiently stable and the final 3.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
-2011):
+As an example, here is how the 3.10 development cycle went (all dates in
+2013):
 
-	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
+	April 28	3.9 stable release
+	May 11		3.10-rc1, merge window closes
+	May 20		3.10-rc2
+	May 26		3.10-rc3
+	June 2		3.10-rc4
+	June 8		3.10-rc5
+	June 15		3.10-rc6
+	June 22		3.10-rc7
+	June 30		3.10 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
@@ -92,34 +91,41 @@ release is made.  In the real world, this kind of perfection is hard to
 achieve; there are just too many variables in a project of this size.
 There comes a point where delaying the final release just makes the problem
 worse; the pile of changes waiting for the next merge window will grow
-larger, creating even more regressions the next time around.  So most 2.6.x
+larger, creating even more regressions the next time around.  So most 3.x
 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 consisting of Greg Kroah-Hartman.  The stable team
-will release occasional updates to the stable release using the 2.6.x.y
+will release occasional updates to the stable release using the 3.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.
+for example, the 3.7 kernel's history (2012/2013) looked like:
+
+	December 10	v3.7 stable release
+	December 17	v3.7.1
+	January  11	v3.7.2
+	January  17	v3.7.3
+	January  21	v3.7.4
+	January  27	v3.7.5
+	February 3	v3.7.6
+	February 11	v3.7.7
+	February 14	v3.7.8
+	February 17	v3.7.9
+	February 27	v3.7.10
+
+3.7.10 was the final stable update for the 3.7 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)
+	2.6.32	Willy Tarreau
+	3.0	Greg Kroah-Hartman
+	3.2	Ben Hutchings
+	3.4	Greg Kroah-Hartman
 
 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
@@ -199,8 +205,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 9,500 patches which went
-into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus
+repository: Linus Torvalds.  But, of the over 13,500 patches which went
+into the 3.10 kernel, only 70 (around 0.5%) 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
 way the kernel developers have addressed this growth is through the use of
@@ -276,7 +282,7 @@ mainline get there via -mm.
 The current -mm patch is available in the "mmotm" (-mm of the moment)
 directory at:
 
-	http://userweb.kernel.org/~akpm/mmotm/
+	http://www.ozlabs.org/~akpm/mmotm/
 
 Use of the MMOTM tree is likely to be a frustrating experience, though;
 there is a definite chance that it will not even compile.
@@ -287,7 +293,7 @@ the mainline is expected to look like after the next merge window closes.
 Linux-next trees are announced on the linux-kernel and linux-next mailing
 lists when they are assembled; they can be downloaded from:
 
-	http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/
+	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
 
 Some information about linux-next has been gathered at:
 
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists