This is losely based on previous discussions on linux-kernel [1][2][3].

Lets also refer people reading the stable rules to

Documentation/development-process/.
Also add the number of days it has taken between releases,

and provide the average for the last 10 releases: 86.0 days.
[1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2

[2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2

[3] http://marc.info/?l=linux-kernel&m=124515657407679&w=2
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

---

 Documentation/development-process/2.Process |  158 +++++++++++++++++++++++++--

 Documentation/stable_kernel_rules.txt       |    5 +

 2 files changed, 153 insertions(+), 10 deletions(-)
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process

index d750321..d4ca05d 100644

--- a/Documentation/development-process/2.Process

+++ b/Documentation/development-process/2.Process

@@ -7,20 +7,158 @@ course of one year, the kernel has since had to evolve a number of

 processes to keep development happening smoothly.  A solid understanding of

 how the process works is required in order to be an effective part of it.
+2.0:SUMMARY

+

+This section provides a brief summary of the kernel release rules.

+

+2.0.0: KERNEL RELEASE RULES

+

+Stable kernels are released when they are ready! This means there are

+absolutely no strict guidelines for sticking to specific dates for a

+kernel release.

+

+2.0.1: PATCH QUEUING FOR THE NEXT KERNEL RELEASE

+

+Linus maintains the development kernel, this means he accepts new

+features and drivers for the next kernel release. He however does not

+maintain every single line of the kernel. The kernel is broken down by

+different subsystems and each subsystem has its own maintainer. In order

+to aid the development of Linux maintainers subsystem have trees where

+they queue patches for the next kernel release. This is typically done

+with a foo-next-2.6.git tree where f...
[ message continues ]

"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
Hi Luis,
Is there a reason not to renumber this whole file, making this section

2.1 and incrementing everything else further down?  It just stands out

from the rest of the document by having a 2.0 section, as well as having

all of the 2.0.x subsections.  It's probably fairly minor, but it does

make this chunk look very different than the rest of the
The bang (!) seems unneeded.
The second sentence seems to have an overabundance of modifiers, perhaps

something like: This means there are no strict guidelines, in terms of
I don't quite follow: In order to aid the development of Linux

maintainers subsystem have trees ...
is there a missing comma and/or some missing words?
Is the "foo-next-2.6.git" convention that widespread?  It just seems

like subsystem maintainers have various ways they track things for the

next development release, but maybe I am wrong.  If not, though, perhaps

toning "typically done" down some, and using it as an example of how it
as a breeding and testing ground for bleeding edge patches. (sounds
The first sentence seems to overstate the case somewhat ... new patches

are welcome most any time, not necessarily accepted ... I suspect (but

don't know for sure) that there are times when subsystem trees are
"between a stable kernel release and prior to the rc1 kernel release"
to address regressions and fix bugs introduced by the new features added
That seems a little strange to say ... if they wish to target deadlines,

they can't work without consideration for inclusion into a specific

kernel, can they?
I think you are trying to suggest that they *not* target deadlines, but
prior to the last rc kernel release, chances are ...
before and after the merge window closes.
These patches are targeted for the new kernel currently under

development. (or something like that, "targeted for the kernel prior to
This could be simplified substantially: Before the merge window closes,

Li...
[ message continues ]

I would say, to address regressions and fix bugs. Not only those added
This is IMHO uncertain. Typical, but uncertain. I guess the maintainer

would already know what to do so I'm not sure there is a point to write
                      ^^^^^^^^^^^

I guess it depends on many factors, such as importance of the bug vs the

risk at the given point. Intrusive bug fixes are sometimes unavoidable
Doesn't make sense. Merge window = new features. Fixes can be accepted
Given that fixes are accepted anytime (well, almost, depending on risk

vs gain), then obviously fixes for new driver aren't worse.
Perhaps it's just me :-) but I think we're trying to codify the rules

way too much. The general rules (merge window = new features etc) are

obviously ok but why do we need strict details like intrusive vs

non-intrusive etc? People should just use a common sense and good

judgement and, if in doubt in some particular case, ask. We are unable

to describe all situations in a single text file.

--

Krzysztof Halasa

--

Me2 :)
That may be a flaw in some parts of this doc is that it tries to

get too detailed, too rigid, etc. for a process that is more fluid and

has lots of independent parts each working in its own slightly

different way.  It does seem like there is value in much of what's

here, but there just aren't any black-and-white rules for exactly how

patches are handled.
jake
--

Jake Edge - LWN - jake@lwn.net - http://lwn.net

--

Well, I do agree that documenting the rules and making them inflexible

shouldn't be the primary goal.
But the fact is, "common sense" hasn't worked very well. I consistently

get pull requests from maintainers that have well-meaning "fix bugs" in

them, and that cause a lot of totally pointless churn.
In fact, this whole discussion has shown one thing: people still think

that "bug fix" somehow automatically means that it's appropriate after the

merge window. That's simply not so. 
			Linus

--

On Tue, Jun 23, 2009 at 12:11 PM, Linus
And that really was the goal of this documentation extension patch, to

clarify that fact. I'm sure Jonathan can do a better job than what I

am trying though, with the added benefit he won't create words out of

thin air :)
  Luis

--

That's why i wrote: gain vs risk.

--

Krzysztof Halasa

--

People really don't seem to be very good at the risk management part. They

see the gain, they don't think about the risk.
Note: not all maintainers are bad about this. But it tends to be my

biggest gripe after around -rc3 or so - people send stuff that is good,

but that really has no real reason not to be delayed.
And as long as people talk about this in terms of "bugs", it's a problem.
It would be much better to talk about it in terms of "Does this _really_

have to hit the next release? Honestly? Even though we're supposed to be

in the calming-down period?"
			Linus

--

Makes sense.  It certainly is counter-intuitive sometimes, though.

Just to clarify, there would seem to be one other category of bugs that

is reasonable post-merge-window: those introduced by new features (or

bug fixes) that were added during the merge window (i.e. something

found in testing the new code during the -rc cycle). Those don't

necessarily have to be security/oops problems and, for the most part,

can't be regressions (at least for new features).  Or should those

wait, by and large, for the next merge window?
jake
--

Jake Edge - LWN - jake@lwn.net - http://lwn.net

--

The thing is, I don't take bug fixes late in the -rc just because they are

bug fixes.
And I really shouldn't.
If it's an old bug, and doesn't cause an oops or a security issue, it had

damn well better wait for the next merge window. There is absolutely _no_

reason to just blindly "fix bugs" at the end of the rc stage, because

quite frankly, the risks coming from fixing a bug is often bigger than the

advantage.
Even "obvious bugs" may be things that people depend on, or that other

parts of the kernel simply rely on indirectly. For a recent example of

this, see what happened when we fixed an obvious bug on x86-64 to check

user space addresses properly: it turns out that 'strnlen_user()' depended

on the bug ("misfeature"), and had to be fixed when the bug was fixed.
So no. Regressions really are _different_ from "fixing bugs".
Regressions need to be fixed even if it may even re-introduce another

long-time bug - simply because we're much better off with a _consistent_

set of bugs where people can depend on their machine either working or

not, than with some kind of unstable situation that never gets anywhere

(we found that out the hard way with both ACPI and power management).
So the end result is:
 - we always want to fix bugs
 - but the primary time to fix bugs is during the merge window
 - after the merge window closes, the effort should be on _regressions_,

   nothing else.
 - security issues and oopses etc catastrophic bugs obviously need to be

   handled at any stage.
IOW, "it fixes a bug" is _not_ sufficient. The real issue is "it _really_

can't wait to the next merge window", not "bug or not".
				Linus

--

Yeah.. to be honest I was just being lazy. But you're right. I'll take another

stab at it but will probably need to then start touching other parts of the

current doc I was trying to avoid editing as I think Jonathan already did
You're right, thanks, will add that. Since you bring this up, are there
Thanks for pointing this out, any particular example in mind? But anyway, will
Its possible, I tend to use wireless-testing for example, whether that is

on 2.6.30 or soon 2.6.31, either way I just use John's wireless development
Oh I see, yeah you're right. This could use some more clarification.

What I was trying to say is it is hard to make a judgement call of

when you're work will get merged with certainty, prior to submission

to the development trees and review from the community, and recommending
I am under the impression that during the merge window maintainers generally

won't accept non-intrusive bug fixes. That is, bug fixes which are simple but

yet do not address a specific existing regression, security hole, or kernel

oops/hang.
I suppose this could use some more elaboration since it seems it may not have
Well I take it that the maintainers who know they can get away with some excemptions

here don't need to read this to figure that out. But I suppose it may be worth

mentioning excemptions do exist, for the record. BTW, just curious, are there any
Right so I don't think I was conveying what I meant appropriately

and I think this could use some more clarification. The point here was

that patches which do not address a regression, kernel oops/hang, or

security issue but yet are non so intrusive, and may fix something small
Heh yeah, that should be clarified, I thought it was based on the text that

outlined the development trees and queing patches.
But if you are asking me, yes, non-intrusive changes should ideally go in

the development trees prior to the merge window. And I thought the documention

patch was highlighting that there is also a chan...
[ message continues ]

Hmm, it seems like I have seen a wide variety of tree names and/or

branch names included in the git pull requests ... also, the tree/branch

names used in linux-next:

http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.Inclu...
I think you have created a new word: excemptions :)  I kinda like it,

but I think you mean exceptions.
I think there are multiple examples of new features being merged after

-rc1, but nothing comes to mind immediately ... I think the plan is to

only add features during the merge window, but it occasionally gets
Jon may have some comments, when he has a chance to look ... let's see

where it goes from there ...
jake
--

Jake Edge - LWN - jake@lwn.net - http://lwn.net

--

Actually, no, I've been treating drivers/staging/ under the same merge

rules at the moment as the rest of the kernel.
thanks,
greg k-h

--

--