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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
