Release management issues [LWN.net]

Is the 2.5 kernel ready to move to the next stage? Linus, in the 2.5.70 announcement, talked about his plans to start the pre-2.6 series of releases. That remark drew a complaint: with all that remains broken in 2.5, how could any plan to create a pre-2.6 release be taken seriously? Linus is unsympathetic, however:

Would I prefer to have everything fixed by 2.6.0 (or even the pre-2.6 kernels)? Sure, everybody would. But it's just a fact of life that we won't see people who care about the issues before that happens. In fact, judging by past performance, a lot of things won't get fixed before the actual vendors have made _releases_ that use 2.6.x ...

This issue comes up over and over again in free software development, of course. Truly getting the bugs fixed requires a very broad base of testers. But most of those testers will not show up until you present them with something billed as "stable" or close to it. Of course, there are dangers in presenting an "almost stable" release too soon; a kernel with too many problems could simply drive those testers away for a long time.

The decision on when to jump into the pre-2.6 series will be a hard one. Quite a few kernel developers seem to think that the time has not yet come. Linus may be ready to make his move sooner rather than later, however. (It is worth noting, incidentally, that the various bureaucratic obstacles to having Andrew Morton work with Linus on the 2.6 release, and eventually take it over, appear to have been overcome. That bodes well for the whole process.)

On the 2.4 front, the official 2.4.21 kernel may be out by the time you read this. No doubt many will be happy to see this long-delayed kernel; 2.4.20 was released on November 28 - a full six months ago. Even so, there are a few complaints, particularly about the omission of a new set of driver fixes. David Miller was one of a few who spoke out:

I really think 2.4.x development is becoming almost non-existent lately... If Conectiva needs to task Marcelo to so much work that he can only really put 1 or 2 days a week into 2.4.x, this needs be rethought at either one end (Conectiva finding a way to give him more 2.4.x time) or another (Marcelo splits up the work with someone else or we simply find another 2.4.x maintainer).

A few developers seconded this complaint, with one or two, perhaps somewhat prematurely, throwing their hats into the ring to be Marcelo's replacement. Marcelo has responded by saying that things will change - 2.4.22 will come out much more quickly. He has also offered to pass on the 2.4.x responsibility should the community think he is not up to the job. There have not been a whole lot of complaints about the kernels that Marcelo has released, however; the only problem is the frequency with which they are produced. Nobody really wants to see him hand the job off to somebody else. But there will be a lot of eyes on the 2.4.22 release process.

to post comments

Release management issues

Posted May 29, 2003 1:31 UTC (Thu) by arcticwolf (guest, #8341) [Link] (1 responses)

Hasn't Marcelo said that the release process would speed up considerably after 2.4.20 was released, too? I don't want to belittle his efforts in putting out the best and most stable kernel he can in any way, but it certainly does seem that he's not able to handle the workload (for whatever reason). Accepting a helping hand would be no shame at all.

Release management issues

Posted Jun 5, 2003 8:30 UTC (Thu) by MLKahnt (subscriber, #6642) [Link]

I suspect that it may be more notable at this point because people are waiting for an official kernel, post-ptrace security escalation problem. Marcelo's official kernels, once released, have been solid, and the presence of -pre## editions have also helped to ensure that bad oversights don't slip through as official kernels, and I do cut him much slack given that, unlike Alan Cox, he hasn't been doing this for years, so it may not be automatically second nature for him yet.

It is just that some of us are not as comfortable applying a patch to the kernel for a security problem, for fear of doing it wrong and getting at best code that doesn't build, at worst code that builds and runs fine, and opens the system wider than ever for unauthorised exploitation. I know that I'd rather have a kernel *done right* that I can build appropriately for my systems.

Andrew Morton & Linus?

Posted May 29, 2003 19:38 UTC (Thu) by pflugstad (subscriber, #224) [Link]

(It is worth noting, incidentally, that the various bureaucratic obstacles to having Andrew Morton work with Linus on the 2.6 release, and eventually take it over, appear to have been overcome. That bodes well for the whole process.)

Eh - what's this about? First I've heard of any problem with this.

Release management issues

Posted May 29, 2003 22:11 UTC (Thu) by iabervon (subscriber, #722) [Link]

It seems logical to me that 2.6-pre would signal a proper freeze; the deadline-based freeze is fine for determining when to stop including new stuff, but a numbering system change should be required to go from kernels which aren't supposed to be stable (2.5.X) to kernels which would ideally be stable but aren't (2.6-preX) to kernels which actually are stable (2.6.X).

Of course, the 2.6-preX series should probably be about 50 kernels (judging by the 2.4 stabilization), but making sure that things head towards 2.6.X and 2.6.0 doesn't come out broken is Andrew's job, and Andrew's job only starts with 2.6-pre1 (or, I suppose, the moral equivalent).

It's unreasonable to except that the first non-development kernel will be not entirely broken, because the last development kernel, by definition, includes new development which has not been widely tested.

On the other hand, I'm not entirely convinced that development is done or nearly done. What would be interesting, actually, is a list similar to the 2.6.0 must-fix list of 2.6-pre "must-break" items; all of the remaining destabilizing changes which are expected in the 2.6 timeframe.

Release management issues

Posted Jun 1, 2003 12:48 UTC (Sun) by stock (guest, #5849) [Link]

As our holy father in heaven states :

release many, release often :)

Also release when its needed. In case of exploits and security matters the
stable branch should be updated without hesitating. Only thinking about
money or distro related marketing management issues won't get us all
anywhere. So the next maintainer should be able to operate independantly
from any commercial linux distro vendors.

Robert