Re: stable? quality assurance?

[David Newall <davidn@davidnewall.com>]

Theodore Tso wrote:
> What this means is yes that stable basically means, "stable
> for the core kernel developers".   You can say that this isn't
> correct, and maybe even dishonest, but if we wait until 2.6.34.N
> before we call a release "stable", and this discourages users
> from testing 2.6.34.M for M<N, it just delays when bugs will
> be found and fixed.
>   

Calling it stable instils and reinforces a Pavlovian response in typical 
users, that recent Linux kernels are dangerous and unreliable; one year 
old was suggested as a safe benchmark. Typical users being 99% of the 
population, testing hardly begins until a kernel is "sufficiently old." 
This Pavlovian response is what really delays finding and fixing bugs. 
Being up-front and saying which kernels are likely to fail would help 
many users calculate the risk and improve their willingness to try newer 
kernels. "Sufficiently old" might well come down to six months, maybe four.

That is to say, instead of taking a year to pass gamma-testing, new 
kernels could be passed in six months or less. That would be a big 
improvement in stability and quality assurance however you dice it.


> But demanding that kernel.org become "more stable" when it
> is supported by purely volunteers is simply not reasonable.

Let's not be hysterical; nobody made any demands. Semantics aside, the 
suggestion is reasonable because it affects developers' workloads not 
one whit. The only change is the label that Linus applies to new releases.