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

kwrohrer@enteract.com
Sun, 8 Feb 1998 21:10:32 -0600 (CST)


And lo, Horst von Brand saith unto me:
> Rik van Riel <H.H.vanRiel@fys.ruu.nl> said:
> > We don't need three trees for that. It would be enough if
> > we have:
> > - a mainline development tree, of which we
> > - split off a stable version (every once in a while), which
> > we bug-fix, but don't add new features to. A splitoff
> > would preferably occur just before a major change in the
> > kernel occurs.
>
> Exactly! Instead of worrying about just two kernel series, have Linus and
> the core hackers worry about three! Just incredibly cuts down on the work
> these *extremely* busy people have to do!!
Three trees versus two is not the idea. On the other hand, 2.2 being
2.1-pre-dentries stabilized, and 2.3 being 2.2+dentries, would have been
nice. Maybe even 2.1-pre-knfsd should have been stabilized to form
2.2, but that's less clear, as knfsd is optional even for nfs servers.

"Only vary one thing at a time" is a golden rule in hard science. In
programming this is not the case (though perhaps it should be), but that
doesn't mean that the opposite extreme is anywhere near optimal either...


> Get real, please: The time of the core people working on Linux is an
> extremely scarce, precious commodity. If you want to backport changes from
> 2.1.xx to 2.0.xx, go and support the Linux Maintenance Project (lmp) [Is it
> still alive, BTW?]. If you want 2.2.1 earlier, either fix 2.1.xx or pay
> someone to do it for you. Just *don't* scream about 2.2.1 being overdue:
> It's not, in the opinion of the people who are entitled to say so. And, if
> MHO counts for anything, what I see on this list is that there are still
> major points to be resolved, rough edges to be smoothed and many nits to be
> picked. So, 2.2.1 is still rather far away.
Well, Linus (and others?) suggested a feature freeze about 10-20 patchlevels
ago, then along came massive sound driver changes plus the IO-APIC stuff.
These are each major changes and put off 2.2 by a fair bit. In their
defense, they seem to be an attempt to merge already-written code into 2.1
(non-CVS) to get it and the core stable together, and a much-needed
cleanup of SMP interrupt handling, respectively.

So while I can't say "don't work on new features", and can't necessarily
tell whether a given change is a new feature or just a Right Thing fix
that entails more fixes elsewhere, let's please do what we can to get
2.1 stable again even if we're not heading for 2.2. While I may be a
bit myopic here, 2.1 has been worse, repeatedly and consistently, than
any series of Linux kernels I've dealt with (going back as far as 0.95
or so). Regardless of whether the current development version should
be 2.1, 2.3, or 2.9 by now, let's all stop flaming each other and fix
those bugs (which we all know are the true causes of our ire and
frustration :-))!

Keith

-- 
"Quartz glyph jocks vend, fix, BMW."  -- 1990 IOCCC judges
The Decline of Western Civilization:  Native Americans revered Raven and 
Coyote.  Our parents watched Moose and Squirrel.  Our children drool on 
Microsoft Barney and Tickle Me Elmo.          http://www.enteract.com/~kwrohrer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu