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 <[email protected]>
Cc: Willy Tarreau <[email protected]>
Cc: Ben Hutchings <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
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
Hi Paul,
Good work!
On Mon, 15 Jul 2013 19:34:44 -0400 Paul Gortmaker <[email protected]> wrote:
>
> 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/
Maybe:
" git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Or as patches relative to Linus' latest -rc or releases from:
https://www.kernel.org/pub/linux/kernel/next/
Or viewed online at:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
"
Or maybe that is a bit verbose.
--
Cheers,
Stephen Rothwell [email protected]
[Re: [PATCH] Documentation: update references to v2.6.x in development-process] On 16/07/2013 (Tue 10:15) Stephen Rothwell wrote:
> Hi Paul,
>
> Good work!
>
> On Mon, 15 Jul 2013 19:34:44 -0400 Paul Gortmaker <[email protected]> wrote:
> >
> > 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/
>
> Maybe:
>
> " git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
> Or as patches relative to Linus' latest -rc or releases from:
>
> https://www.kernel.org/pub/linux/kernel/next/
>
> Or viewed online at:
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
> "
>
> Or maybe that is a bit verbose.
Probably no harm in it. I'd cc'd you and akpm for exactly that reason;
I wasn't sure I'd updated to the authoratative source. I'll fold that
into a v2 once there has been a chance for other feedback to come in.
On a similar note, I was thinking about the recent thread on linux-next
where we were indicating that people shouldn't rebase linux-next content
on a whim, and that new devel (vs. bugfix) content shouldn't appear in
the linux-next content during the merge window. There is no question
that the linux-next process is integral to the main flow of patches to
mainline, so I think Documentation/development-process/2.Process (the
same file) should also capture those points in the linux-next section.
Do you have some pre-canned text we can insert there, or should I draft
something up for you to review?
Thanks,
Paul.
--
> --
> Cheers,
> Stephen Rothwell [email protected]
Hi Paul,
On Mon, 15 Jul 2013 22:13:50 -0400 Paul Gortmaker <[email protected]> wrote:
>
> On a similar note, I was thinking about the recent thread on linux-next
> where we were indicating that people shouldn't rebase linux-next content
> on a whim, and that new devel (vs. bugfix) content shouldn't appear in
> the linux-next content during the merge window. There is no question
> that the linux-next process is integral to the main flow of patches to
> mainline, so I think Documentation/development-process/2.Process (the
> same file) should also capture those points in the linux-next section.
> Do you have some pre-canned text we can insert there, or should I draft
> something up for you to review?
The latter would be certainly easier for me :-) If that is not easy, let
me know and I will write something (even without swearing ;-)).
--
Cheers,
Stephen Rothwell [email protected]
On Mon, 2013-07-15 at 19:34 -0400, Paul Gortmaker wrote:
[...]
> 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
[...]
You could also link to <https://www.kernel.org/releases.html> here.
Ben.
--
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
[Re: [PATCH] Documentation: update references to v2.6.x in development-process] On 16/07/2013 (Tue 13:50) Stephen Rothwell wrote:
> Hi Paul,
>
> On Mon, 15 Jul 2013 22:13:50 -0400 Paul Gortmaker <[email protected]> wrote:
> >
> > On a similar note, I was thinking about the recent thread on linux-next
> > where we were indicating that people shouldn't rebase linux-next content
> > on a whim, and that new devel (vs. bugfix) content shouldn't appear in
> > the linux-next content during the merge window. There is no question
> > that the linux-next process is integral to the main flow of patches to
> > mainline, so I think Documentation/development-process/2.Process (the
> > same file) should also capture those points in the linux-next section.
> > Do you have some pre-canned text we can insert there, or should I draft
> > something up for you to review?
>
> The latter would be certainly easier for me :-) If that is not easy, let
> me know and I will write something (even without swearing ;-)).
I'll do something for the latter, but I can't promise to refrain from
swearing... ;-)
Thanks,
Paul.
--
>
> --
> Cheers,
> Stephen Rothwell [email protected]
On Mon, 15 Jul 2013 19:34:44 -0400
Paul Gortmaker <[email protected]> wrote:
> 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.
Ccing the author of the document never hurts :)
I actually went through this exercise a while back, but somehow never got
around to sending the changes out into the world. Easily distracted, I
guess. Anyway, you can put my Acked-by on your changes if you like.
> On a similar note, I was thinking about the recent thread on linux-next
> where we were indicating that people shouldn't rebase linux-next content
> on a whim, and that new devel (vs. bugfix) content shouldn't appear in
> the linux-next content during the merge window. There is no question
> that the linux-next process is integral to the main flow of patches to
> mainline, so I think Documentation/development-process/2.Process (the
> same file) should also capture those points in the linux-next section.
> Do you have some pre-canned text we can insert there, or should I draft
> something up for you to review?
Seems useful, I could also try to help with this if you run out of steam.
I'd be more inclined to put it into section 7, though, since it's the sort
of thing early-stage developers don't normally need to worry about.
Thanks,
jon
On 13-07-16 01:33 PM, Jonathan Corbet wrote:
> On Mon, 15 Jul 2013 19:34:44 -0400
> Paul Gortmaker <[email protected]> wrote:
>
>> 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.
>
> Ccing the author of the document never hurts :)
It might be worth sticking an entry in MAINTAINERS for that dir.
If one had asked me who wrote it, I probably would have recalled that
info, but instead I just out of habit ran get_maintainers...
>
> I actually went through this exercise a while back, but somehow never got
> around to sending the changes out into the world. Easily distracted, I
> guess. Anyway, you can put my Acked-by on your changes if you like.
Thanks.
>
>> On a similar note, I was thinking about the recent thread on linux-next
>> where we were indicating that people shouldn't rebase linux-next content
>> on a whim, and that new devel (vs. bugfix) content shouldn't appear in
>> the linux-next content during the merge window. There is no question
>> that the linux-next process is integral to the main flow of patches to
>> mainline, so I think Documentation/development-process/2.Process (the
>> same file) should also capture those points in the linux-next section.
>> Do you have some pre-canned text we can insert there, or should I draft
>> something up for you to review?
>
> Seems useful, I could also try to help with this if you run out of steam.
> I'd be more inclined to put it into section 7, though, since it's the sort
> of thing early-stage developers don't normally need to worry about.
I'd agree with that; a pointer in section two where linux-next is 1st
mentioned can point to section7 where the advanced info is given.
Paul.
--
>
> Thanks,
>
> jon
>
On 07/17/2013 08:34:08 AM, Paul Gortmaker wrote:
> On 13-07-16 01:33 PM, Jonathan Corbet wrote:
> > On Mon, 15 Jul 2013 19:34:44 -0400
> > Paul Gortmaker <[email protected]> wrote:
> >
> >> 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.
> >
> > Ccing the author of the document never hurts :)
>
> It might be worth sticking an entry in MAINTAINERS for that dir.
> If one had asked me who wrote it, I probably would have recalled that
> info, but instead I just out of habit ran get_maintainers...
I note that every file people stick a MAINTAINERS entry for in
Documentation is one that I _don't_ bother with. Just FYI.
(Yes, 5 days behind on the list, but catching up...)
Rob-