Re: suggestion.

[David Ford <david@kalifornia.com>]

James Bourne wrote:

> On Sun, 11 Jun 2000, David Ford wrote:
>
> > I differ in opinion here, 2.2 is full of bugs which have been fixed in
> > 2.3/2.4.  I suggest we start with the most current code base.  There is
> > little merit in duplicating work that has already been done.  2.4 is at
> > the door, almost ready to walk.
>
> I agree with the former.  How many servers which need stability and are too
> much of a pain to upgrade are still running a 2.0 kernel?  2.2 will be
> around for a long time (it's really just starting to get good and stable
> now) and when 2.4 does come out, it will be the same ball of hair, not being
> fully accepted until it stablizes.  Anything caught in 2.2 can be of use in
> 2.4 to some extent at least.

The point is, many of the bugs, races, and security flaws in older kernels have been
fixed in the current tree.  We can expend a lot of effort fixing old stuff that's already
been fixed in the current tree, or we can make a good impression and come out with good
stuff in the first place.  A lot of problems in the 2.0 and 2.2 trees will remain there
unless a third party plans on doing the work simply because the evolution through the
2.odd tree is a significantly large amount of work.

There is often talk about old kernels on lkml and requests for backports and explanations
why the broken widget in 2.even won't get fixed because of the amount of effort it will
take to do it.  Some fixes simply aren't possible because they are intimately tied to API
changes throughout the rest of the kernel.

It's a nice idea to fix critical things in the old trees, but it's comparable to fixing
inadequacies in the 65 Mustang.  Contrary to your idea of finding bugs in 2.2, most bugs
are actually found in 2.odd and if critical, a backport fix is made for 2.even.

Chances are strong, for most of the bugs found in 2.2, when you bring up discussion of
it, you are likely to find it's already fixed in 2.3.  There are two points to a new
version of software, bug fixes and features.  Luckily for us, LK places a heavy emphasis
on bug fixes, much more heavily than new features.  Linus is really insistent on Do It
The Right Way (tm).

New code is always going to have bug fixes already applied to it that will reduce the
amount of work required.  Old code is always going to require bug fixes that frequently
have already been accomplished, increasing our workload because once a bug is found you
have to verify it hasn't already been fixed.

So again, I venture that our primary focus should be the current tree.  Review the
current tree and apply backwards versus review old code and apply forward.

-d


--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."


begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard