public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Newall <davidn@davidnewall.com>
To: Marcin Letyns <mletyns@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: stable? quality assurance?
Date: Tue, 13 Jul 2010 01:26:41 +0930	[thread overview]
Message-ID: <4C3B3B39.2000809@davidnewall.com> (raw)
In-Reply-To: <AANLkTilGjfx9sb66qVfZn1SeFPURHUrrdE7JCrild8VX@mail.gmail.com>

Marcin,

>> I don't expect fair consideration of these comments; why change when
>> shooting the messenger is so much more satisfying?
>>     
Q.E.D.


First, for the sake of brevity, I want it agreed that we're talking 
about new kernels, not those which are old, time-tested and patched.

I didn't notice anyone say they want Linux development to slow down; 
rather, and not just in this thread but in many threads before, that 
kernels released as "stable" fail to meet the common meaning of that 
word; and this needs to be improved.  Predictably, the common response 
sounds a bit like "shut up, go away, you're an idiot, it doesn't happen 
to me."  These are not useful as they serve not one whit to improve the 
situation, but give pause to those who might otherwise want to bring up 
a valid issue, once more.

Expectations are key to the problem.  When Linus says, "here is a shiny 
new, stable kernel", he creates expectations.  When that kernel proves 
unstable, those expectations are dashed and confidence in Linux 
suffers.  There's no reason why development methods need to change in 
order to reduce the number of flaky "stable" kernels.  It would be 
sufficient to replace the somewhat deceptive word "stable" with one that 
is more accurate; beta or gamma test make sense as they already have 
industry acceptance.  Clearly "stable" is not appropriate, as implicitly 
agreed by others who have advised: "don't use in production"; "wait at 
least a year"; and more.

Thus 2.6.34 is the latest gamma-test kernel.  It's not stable and I 
doubt anybody honestly thinks otherwise.

As to whether other operating systems are stable, well that's a fair 
question.  I agree that few large bodies of computer code are flawless, 
and so stability can be relative.  In that spirit I venture to put the 
stipulated kernels into order of decreasing reliability: Best is BSD, 
Solaris & OS X; then Windows; and then there's Linux.  If named 
distributions had been included, the list would look better (for us); 
they'd go in the first group.  Thank goodness for the Debian, Red Hat 
and Novell (to name just a few) for giving the world something which 
does, at least largely, meet expectations.

  parent reply	other threads:[~2010-07-12 15:56 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-11  7:18 stable? quality assurance? Martin Steigerwald
2010-07-11  8:39 ` Eric Dumazet
2010-07-11 14:22   ` Martin Steigerwald
2010-07-11 14:52     ` Martin Steigerwald
2010-07-11 15:58   ` William Pitcock
2010-07-11 16:34     ` Eric Dumazet
2010-07-16  6:59     ` Greg KH
2010-08-05  3:27       ` Jeremy Fitzhardinge
2010-07-11 17:04   ` Heinz Diehl
2010-07-11 13:16 ` Ted Ts'o
2010-07-11 18:02   ` Anca Emanuel
2010-07-12  6:46   ` David Newall
     [not found]     ` <AANLkTilGjfx9sb66qVfZn1SeFPURHUrrdE7JCrild8VX@mail.gmail.com>
2010-07-12 12:35       ` Fwd: " Marcin Letyns
2010-07-12 12:42         ` Alexey Dobriyan
     [not found]           ` <AANLkTik64lxDiCN-eRo3i_-cTqAvCzbaRI4EEXoD44Vj@mail.gmail.com>
2010-07-12 12:52             ` Fwd: " Marcin Letyns
2010-07-12 14:57           ` Valdis.Kletnieks
2010-07-12 15:56       ` David Newall [this message]
2010-07-12 17:48         ` Marcin Letyns
2010-07-12 18:00         ` Stefan Richter
2010-07-12 19:58           ` David Newall
2010-07-12 21:11             ` Stefan Richter
2010-07-12 21:39             ` Martin Steigerwald
2010-07-12 22:44               ` Stefan Richter
2010-07-15  7:23             ` david
2010-07-13 16:50         ` Theodore Tso
2010-07-13 20:45           ` David Newall
2010-07-14  6:33             ` Theodore Tso
2010-09-04 17:12   ` Martin Steigerwald
2010-07-11 13:56 ` Lee Mathers
2010-07-11 14:51   ` Martin Steigerwald
2010-07-11 17:22     ` Willy Tarreau
2010-07-11 21:38       ` Rafael J. Wysocki
2010-07-12  4:17         ` Willy Tarreau
2010-07-12  9:56       ` Martin Steigerwald
2010-07-12 15:43       ` Martin Steigerwald
2010-07-12 17:36         ` Willy Tarreau
2010-07-12 19:56           ` Martin Steigerwald
2010-07-12 23:03             ` Stefan Richter
2010-07-13 10:30               ` Martin Steigerwald
2010-07-15  7:32               ` david
2010-07-12 17:55         ` Stefan Richter
2010-09-04 16:38       ` Martin Steigerwald
2010-09-04 18:46         ` Ted Ts'o
2010-09-04 19:11           ` Martin Steigerwald
2010-09-04 23:23             ` Ted Ts'o
2010-09-05  7:59               ` Martin Steigerwald
2010-09-04 19:24         ` Stefan Richter
2010-09-04 19:34           ` Stefan Richter
2010-09-04 20:21           ` Martin Steigerwald
2010-09-04 22:50             ` Stefan Richter
2010-09-04 23:16             ` Ted Ts'o
2010-09-05  8:35         ` Avi Kivity
2010-09-05  9:48           ` Martin Steigerwald
2010-07-11 19:49     ` Stefan Richter
2010-07-13 11:11     ` Alejandro Riveira Fernández
2010-07-13 12:50       ` rt2x00: slow wifi with correct basic rate bitmap (was Re: stable? quality assurance?) Stefan Richter
2010-07-13 15:35         ` John W. Linville
2010-07-13 18:19           ` Alejandro Riveira Fernández
2010-07-13 18:38             ` John W. Linville
2010-07-13 19:07               ` Alejandro Riveira Fernández
2010-07-13 18:06         ` Alejandro Riveira Fernández
2010-07-13 19:18           ` Stefan Richter
2010-07-12 19:46 ` stable? quality assurance? Nix
     [not found] ` <AANLkTimEdVsmIgXBbmhsq75ElQvGAI8avsM8-wlDpm4z@mail.gmail.com>
2010-07-15  9:09   ` Valeo de Vries
2010-07-16  7:00     ` Greg KH
2010-07-16  7:19       ` Justin P. Mattock
2010-07-16 15:25       ` Randy Dunlap
2010-07-16 15:34       ` Valeo de Vries
  -- strict thread matches above, loose matches on Subject: below --
2010-09-04 16:42 Martin Steigerwald
2010-09-04 17:22 ` Willy Tarreau
2010-09-04 19:33   ` Martin Steigerwald
2010-09-04 20:19     ` Willy Tarreau

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=4C3B3B39.2000809@davidnewall.com \
    --to=davidn@davidnewall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mletyns@gmail.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