Re: 2.1.X and its separation from the Linux User base

James Mastros (root@jennifer-unix.dyn.ml.org)
Sat, 7 Feb 1998 11:06:31 -0500 (EST)

On Fri, 6 Feb 1998, Horst von Brand wrote:
> Ben Woodard <bwoodard@cisco.com> said:
> > Horst von Brand <vonbrand@pc16.usm.edu.ec> said:
> > > I don't much mind if we go up to 2.1 255 before 2.2.0... if we later don't
> > > go past 2.2.4 ;-)
>
> > That sounds like a very cathedralish thing to say. What is the problem
> > with having a few bugfix releases in the stable kernel?
>
> That people expect stable kernels to be stable, period.
>
> > Why not let the experimenters run free in 2.3.xx, the early adopters
> > shake things loose in 2.2.0-10 (or whatever it takes for about two
> > months to go by) and those people that have really critical
> > applications jump in around 2.2.11?
>
> Why not let experimenters play around with 2.1.x? There is plenty of work
> to be done to properly integrate the massive changes made since 2.1.40 or
> thereabouts, there are things that just don't work right now, ...
>
> > It seems like we have a pretty interesting optimzation problem going
> > on here.
>
> > 1) To keep linux moving forward we want to maximize creativity and to
> > avoid the risk of huge diffs and overlapping modifications of code we
> > don't want to have feature freezes for very long.
>
> True.
>
> > 2) We need feature freezes for long enough that all the different
> > sections of the kernel are tried out.
>
> Not quite true: There are parts that are rock solid and throroughly tested
> together with others of a more fluid nature in there.
>
> > 3) To keep linux stable, we want to maximize the number of people
> > working with it and therefore exposing bugs in it.
>
> This is (mostly) granted by the huge influx of new users. But new users
> bring new, weird machines and requirements with them too...
>
> > 4) To keep linux's reputation we want to show the world that you make
> > things right the first time.
>
> So _don't_ call for pushing a beta kernel out of the door then!

Push a beta kernel out the door -- call it pre-2.2.0-1. (When everything
seems to be stable in 2.1... the pre-2.2 testers can find all the remaining
bugs, and hopefully will. If sombody wants to be really nice, they can make
a kernel module to load under 2.0.x to look for behivor that won't work in
2.2.x.)

> > It seems to me that one way to accomplish these goals would be to make
> > three trees instead of two. A stable 2.0,
>
> Done.
>
> > a coming to convergence 2.2
> > beta followed by official 2.2's
>
> It's called 2.1.x right now, and will be called 2.2.1 soon enough. Just
> don't push out a "stable but beta" series! The "middle number even means
> stable" is entrenched in Linux culture, if a 2.2.1 comes out, everybody
> will assume it's stable.
Right. So make a 2.2.0-pre1, a 2.2.0-pre2, etc. until ALL bugs are out, and
everything has been tourture-tested.

> But in your scheme it won't be. And saying "2.2.1
> but for testers only" doesn't buy you anything 2.1.x + feature freze couldn't
> give you, testers _are_ running 2.1.85, that you don't hear much about that
> just means that it mostly works fine. There are reports of bugs, there are
> reports to the egcs (experimental gcc strand) lists about bugs in egcs or
> Linux uncovered by compiling various kernels.
Then we either need to fix them or officaly say that egcs-compiled kernels
are a no-no. I would really much prefer the former to the later, if at all
possible (for example, there is a known workaround to the volitle flag
failing on casts: apply it in paramater lists or varable declarations.

> > and a 2.3. Another way to approach it
> > would be to move to the next stable release shortly after the freeze
> > and let the kernel converge there.
>
> I don't think so. I like the current model, and many people complained
> bitterly about the not-absolutely-rock-solid-for-everyone qualities of
> 2.0.1, don't repeat that mistake now.
Exactly. On the other hand, keep an absolute feature freze, and don't start
2.3 until a real 2.2 is out the door. Changing from a 2.1.x strand to a
2.2.0-preX strand would do that.

-=- James Mastros

PS -- I don't think that 2.3 should last nearly as long as 2.1 did -- one
major improvement, and that's it. IMHO, we could have had a 2.2 by now if
sombody hadn't jumped the gun on the SMP IRQ changes <G>. That would have
two major re-designs: the dcache and smart-config. Now we are working on
getting the bugs out of the third.

-- 
   "I'd feel worse if it was the first time.  I'd feel better if it was
   the last."  
   	-=- "(from some Niven book, doubtless not original there)" 
	    (qtd. by Chris Smith)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu