public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: John Alvord <jalvo@mbay.net>
Cc: David Relson <relson@osagesoftware.com>, linux-kernel@vger.kernel.org
Subject: Re: Kernel Releases
Date: 25 Nov 2001 08:46:29 -0700	[thread overview]
Message-ID: <m1d726zwdm.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.20.0111242147500.26049-100000@otter.mbay.net>
In-Reply-To: <Pine.LNX.4.20.0111242147500.26049-100000@otter.mbay.net>

John Alvord <jalvo@mbay.net> writes:

> Development kernels are development kernels... nothing else. Look to
> distributors for high degrees of quality assurance testing. When you run a
> development kernel you have joined the development team, even if you don't
> know it. Finding  and reporting bugs is your job...

Bah.  Some of the worst kernels I have seen have been distributors kernels.
Distributors seem to give in to the desire for more features, and don't
address the deep bugs.  

Now stability and correctness are two different (but related) things in code.
I have seen stable programs and some even a few kernels that were rock solid
reliable and stable but were extremely incorrect in places.

Correctness means you can write a proof showing how it meats it's
specifications.  Stability means something passes the test of time.

If you are correct it is relatively easy to pass the test of time.  If
you are incorrect it is still possible but harder.

What the developers produce primarily are correct kernels, especially
Linus.  I have never seen a distribution make a kernel more correct.
Instead what I have seen is distributors testing on a wide variety of
hardware and for those things that don't work they throw in the
current best work around.

Also distributors during development don't have the same number of
people testing a kernel as the global linux kernel project has.  At
the current point in time it appears that Linus Torvalds is finally
satisfied with the basic correctness of 2.4.x.  Enough so that he
doesn't feel the need to keep fixing it.  So even if 2.4.15 is 
slightly damaged it makes a good base for future stability.

To date Alan Cox has done a great job in maintaining the stable 2.2
series.  Giving us all something we can use reliably without fear.
And while I haven't watched it religiously Alan Cox has done the whole
release candidate thing, which really does help to catch stupid
typos..  And hopefully in his one way Marcello Tosatti will as well.
I honestly expect future 2.4.x kernels to be much more stable.

I have the utmost respect for the work Linus, Alan, and now Marcello
are doing.  Taking on a position where you agree to be flooded with
email.  Being buried in so much management of patches that you hardly
have time to develop yourself.  Waiting in a pre patch, for someone
else to catch your typos.  Patience is a hard thing, as is believe
that somehow you goofed and you need a second pair of eyes to look
at it and fix it.

Now I agree that finding and reporting bugs is still the job of
everyone who runs a Linux kernel in the stable series, but that is
just the final stage of quality assurance.  But this is part of a
larger job that is really finding a way to get the best possible
kernel.  Giving up on that process and figuring it will always result
in a buggy and flaky product looks like the wrong attitude to take.

Linus has admitted he really doesn't have the temperament for
maintaining a long term stable release.  But as we have all seen he
does have the temperament to lead a development kernel.  And his
stepping down now from the stable branch now that the core of the
kernel is correct is the best sign for stability for 2.4.x that I have
seen.  I have yet to see Marcello's work in action but if is anywhere
near as good as Alan's 2.4.16+ should be more stable than anything the
distributors release.

Eric

  parent reply	other threads:[~2001-11-25 16:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-25  4:27 Kernel Releases David Relson
2001-11-25  5:49 ` John Alvord
2001-11-25  6:34   ` CaT
2001-11-25 14:12   ` John Jasen
2001-11-26  7:15     ` John Alvord
2001-11-25 15:46   ` Eric W. Biederman [this message]
2001-11-25 16:23     ` Nathan Walp
2001-11-26 21:03     ` Bill Davidsen
2001-11-25 19:55 ` Phil Sorber
2001-11-26  9:22 ` Allan Sandfeld
2001-11-26 14:51   ` Ian Stirling
2001-11-26 15:02     ` Rik van Riel
2001-11-26 19:11       ` Ian Stirling
2001-11-26 19:55       ` vda
2001-11-26 20:42 ` Bill Davidsen
2001-11-27  4:21   ` Mike Fedyk
2001-11-27  9:50   ` Helge Hafting
  -- strict thread matches above, loose matches on Subject: below --
2001-11-25  5:37 Dan Kegel
2001-11-25  9:25 ` Nathan Dabney
2001-11-25 10:24   ` Keith Owens
2001-11-25 13:34     ` Phil Howard
2001-11-25 19:03     ` Nathan Dabney
2001-11-26 10:46 Martin Knoblauch
2001-11-26 15:27 ` John Jasen
2001-11-26 20:36   ` Horst von Brand
2001-11-27  2:40     ` Gerhard Mack
2001-11-27 17:25 Dan Kegel
2001-11-27 17:36 ` François Cami
2001-11-27 17:38   ` Dan Kegel
2001-11-27 18:13     ` Vitaly Luban
2001-11-28 16:23     ` Horst von Brand
2001-11-28 19:17       ` Mike Fedyk
     [not found] <fa.dac7a7v.1hkofg8@ifi.uio.no>
2001-11-27 17:53 ` Giacomo Catenazzi
     [not found] <Pine.LNX.4.33.0111261807570.489-100000@mikeg.weiden.de>
2001-11-27 18:08 ` vda
2001-11-27 16:58   ` Mike Galbraith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1d726zwdm.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=jalvo@mbay.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=relson@osagesoftware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox