[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C3CD060.50904@davidnewall.com>
Date: Wed, 14 Jul 2010 06:15:20 +0930
From: David Newall <davidn@...idnewall.com>
To: Theodore Tso <tytso@....EDU>
CC: Marcin Letyns <mletyns@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: stable? quality assurance?
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists