linux-kernel - Re: Proposed stable release changes

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, 21 Aug 2013 11:36:05 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	stable <stable@...r.kernel.org>, lwn@....net,
	Guenter Roeck <linux@...ck-us.net>,
	Hugh Dickins <hughd@...gle.com>,
	Johannes Berg <johannes@...solutions.net>,
	Borislav Petkov <bp@...en8.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Proposed stable release changes

On Wed, Aug 21, 2013 at 11:20 AM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 08/20/2013 04:40 PM, Greg KH wrote:
>
> Presumably the idea is that much useful testing only happens on -rc
> kernels rather than linux-next or arbitrary points in Linus' tree.

Linux-next gets little to no testing outside of compiles.

And I don't think the -rc releases are all that important either. The
important part is to _wait_. Not "wait for an -rc". There are
reasonable number of developers and users who actually run git
kernels, just because they want to help. At rc points, you tend to get
a few more of those.

In contrast, when patches get moved from the development tree to
stable within a day or two, that patch has gotten basically _no_
testing in some cases (or rather, it's been tested to fix the thing it
was supposed to fix, but then there are surprising new problems that
it introduces that nobody even though about, and wasn't tested for).

So I don't think "is in an rc release" is the important thing. I think
"has been in the standard git tree for at least a week" is what we
should aim for.

Will it catch all cases? Hell no. We don't have *that* many people who
run git kernels, and even people who do don't tend to update daily
anyway. But at least this kind of embarrassing "We found a bug within
almost minutes of it hitting mainline" should not make it into stable.

              Linus
--
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/