linux-kernel - Re: stable? quality assurance?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/