Re: RFD: Kernel release numbering

Nicolas Pitre
2005-03-04T23:42:29Z

On Fri, 4 Mar 2005, Linus Torvalds wrote:

>
>
> On Fri, 4 Mar 2005, Nicolas Pitre wrote:
> >
> > It might still be worth a try, especially since so many people are
> > convinced this is the way to go (your fault or not is not the point).
>
> Making releases is actually a fair bit of work. Not the script itself, but
> just deciding and trying to synchronize. The fatc that people won't really
> appreciate it anyway, and just complain about "that's not stable anyway"
> just makes me even less interested.

Don't read me wrong.

It's not the work that is being done which is the problem. To the
contrary, the current process is really great and for one I hope 2.7.x
will _never_ happen, and here's why:

Coming from the embedded world I can tell you that 2.5.x was simply too
"instable" to use as a basis for a product, and communities around non
i386 architectures simply don't have enough man power to follow two
kernel trees (2.4.x and 2.5.x) in parallel. The embedded world
therefore ended up developing on 2.4.x only because that was the stable
tree that could bring revenues to sustain said development, even if 2.4.x
was a dead end.

Now the catch up phase on 2.6.x within the embedded world is almost done
and 2.6.x is also where the major developments are happening. It's
therefore way easier for smaller communities to stay in the game since
2.6.x is also stable enough for commercial products despite the rapid
development actually occurring there. There are certainly a few more
stability glitches than you could have found in 2.4.x but overall 2.6.x
is a much better compromise bringing much more value to us -- thanks to
your hard work and Andrew's (and RMK's) and everybody else for making
the current process so efficient and dynamic.

Now back to the current discussion. What people are complaining about
is the lack of testing on the official 2.6.x releases. This lack of
testing comes from the fact that your -rc releases are not seen like
stable enough for the mass to test, and this is due mainly because the
people outside of the development loop have no idea when you actually
called for a patch calm down.

It's not like you don't actually call for a calm down in order to have a
release stabilized because, as Andrew pointed out, you effectively only
merged true bug fixes into 2.6.11-rc[45]. See? You _do_ it and you
_did_ it already.

The only issue is to actually have way more people to jump in and try
out kernels which are in that "calm down" phase. And for that to happen
you need a clear signal to the people outside the development loop who
currently can't trust your -rc releases since they end up including more
than just bug fixes up to a randomly chosen particular -rc.

That's why many are suggesting that you consider switching to -pre
releases for developer sync points, and for the last -pre release where
you call for a calm down. Then subsequent releases are -rc releases
with strictly bug fixes. For example, 2.6.11-rc[123] would have been
2.6.11-pre[123] and 2.6.11-rc[45] would have been 2.6.11-rc[12].

See how this won't change anything to your work methodology besides the
naming? And this has the potential of bringing more testers not closely
following lkml or the commit log (granted that -rc becomes real
release-candidate-bug_fix_only releases but again you do that already)
since they'll see those -rc releases as nearly official releases. Of
course it might not bring the hoped result but it costs nothing to try
it out. That's what I meant in my previous email.

P.S.: this is not incompatible with the "sucker" tree -- in fact both
of those things might be useful and effective for their own purpose.

Nicolas