Re: kernel structures 2.0.29->2.0.30
Jean-Philippe Langlois (jpl@iname.com)
Sat, 26 Apr 1997 17:45:56 -0400
Franz Sirl wrote:
>
> At 1:49 Uhr +0200 26-04-1997, Alan Cox wrote:
> >> modification in a stable release was careful weighted and overcautiously
> >> studied. This is clearly no longer true and I regret it. It seems Linux
> >> developers lost the problem of "pure" users (not developers). 2.0.x
> >> kernels have introduced new stuff and this is not acceptable (the Apache
> >> break in 2.0.14 was specially catastrophic).
> >
> >2.0.14 broke for SMP and Apache only. It broke because a fix that was
> >causing Oopses for people running Apache got fixed. And because the SMP
> >bug was WEEEIIIIIRD it took till .18 to fix.
>
> Ok, the Apache break bit me too, but nobody urged me to upgrade to 2.0.14
> and I didn't had problems with 2.0.13 either. I simply had a little bit
> time to spend to compile and reboot. The "bug" showed up immediately, Ok,
> no problem, rebooted with 2.0.13, wrote a message in Linux-Kernel, got a
> message with a fix a few hours (!) later from Linus. So what's catastrophic
> about that?
>
> >> major change. From 2.0 to 2.1 a smaller change and from 2.0.29 to 2.0.30
> >> just some bug fixes. Otherwise, we are not better than Microsoft which
> >> uses versioning for marketing.
> >
> >One problem we have is no version space for an "incremental upgrade".
> >Solaris for example goes 2.2,2.3,2.4,2.5 and then has the 2.5.1 release
> >which is 2.5 patched and improved a bit but not a major change. 2.0.30
> >is the equivalent of that
>
> I liked the pre-patch approach for 2.0.30 very much, it could avoid many
> real versions. Eventually you could split up the pre-patches into "fixes"
> for real bugs and "improvements" for the other stuff (speed, new
> drivers,...).
> Another approach would be to put fixes with comments on www.linuxhq.com and
> flag them as "Approved for next release". Probably this could even be a
> separate section on linuxhq.
>
> Ciao,
> Franz.
>
I tend to agree with that. Is there a need for a new version everytime
we find a couple of bugs? Why not maintain a list of _approved_ patches
that you can apply to the stable release, as well as a list of _to be
approved_ patches. Adventurous people, or people concerned with the
patches, should then try the patches and give feedback. This way the bad
image of the great number of versions would disappear, and we could get
the same improved code.
> --
> --------------------------------------------------------------------------
> URLs <mailto:Franz.Sirl@munich.netsurf.de>
> <http://homepages.munich.netsurf.de/Franz.Sirl>
> --------------------------------------------------------------------------