Messages in this thread | | | Date | Sat, 7 Feb 1998 11:06:31 -0500 (EST) | From | James Mastros <> | Subject | Re: 2.1.X and its separation from the Linux User base |
| |
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
| |