Re: RFD: Kernel release numbering

[Nicolas Pitre <nico@cam.org>]

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