Re: RFD: Kernel release numbering

From: David Lang
Date: Thu Mar 03 2005 - 23:26:42 EST


On Thu, 3 Mar 2005, Steven Rostedt wrote:

On Thu, 2005-03-03 at 13:24 -0800, David Lang wrote:

I don't think you are understanding the proposal

You're probably right. :-)

2.6.11.y will be released as 2.6.12 is being developed.

once 2.6.12 is released (or shortly after that if 2.6.12 ends up being a
_real_ mess) 2.6.11.y will not get any additional releases (2.6.12.y will
get released instead)

as a result there will be no backports at all. if you want a feature
that's introduced in 2.6.12 then you wait until you get a 2.6.12.y release
that's good enough for you.

I understand the no backports. That's a good thing. That's what I was
trying to state (but was probably too long winded!). Lets see if this
is what I believe is being proposed.

2.6.x would be the release with some number of features added.

2.6.x.y would include bug fixes only, that are under the strong rule of
Linus to only be things that crash/hang the machine or nasty security
exploits.

2.6.x+1 would be 2.6.x.(some y) also including features (from -rc or
-mm)

2.6.x.z (where z is greater than the above "some y") only include the
same level of fixes as with 2.6.x.y, with the parallel work of 2.6.x+1
still going on.

Please correct me if I'm wrong here.

this sounds like what I am understanding.

also I think the expectation is that there aren't going to be more then
2-3 2.6.x.y releases so your comment of people waiting until y>5 won't
apply


Say after 2.6.x.3 has been released and 2.6.x+1 is now out, and someone
finds a rare race condition that hangs the machine. A 2.6.x.4 would not
be released?

my understanding is that in general there would no be a 2.6.x.4 in this case (special cases can cause rules to be bent, a rare race condition probably wouldn't qualify, a remote root security hole probably would)

Actually, the >5 was pretty pointless anyway. What I got
from talking to people is that they wanted a release that only got fixes
that would crash the machine, or cause a root exploit. That's what I
thought Linus was trying to say.

the trouble is that 'crash the machine' can include a HUGE number of the fixes that go into 2.6.x+1 and you just lost stability again

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
-
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/