Re: stable? quality assurance?

[David Newall]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/