[lkml]   [1998]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.1.X and its separation from the Linux User base
Ben Woodard <> said:
> Horst von Brand <> 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.


> 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!

> It seems to me that one way to accomplish these goals would be to make
> three trees instead of two. A stable 2.0,


> 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. 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.

> 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.
Horst von Brand
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean