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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 13 Jul 2013 08:36:07 +0200
From:	Willy Tarreau <w@....eu>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	stable <stable@...r.kernel.org>
Subject: Re: [ 00/19] 3.10.1-stable review

On Fri, Jul 12, 2013 at 11:22:23PM -0700, Greg Kroah-Hartman wrote:
> > So probably we should incite patch contributors to add a specific
> > tag such as "Fixes: 3.5 and later", so that non-important patches
> > do not need the Cc:stable anymore, but users who experience an issue
> > can easily spot them and ask for their inclusion.
> 
> Huh?  What's wrong with the existing way people mark stable patches to
> go back to much older kernel versions?  Is that not working well enough
> for you?
> 
> And if something "fixes" an issue, then I want it in stable, just like
> Linus wants that in his tree.

It's the difference between "this is a fix" and "please backport this
fix into stable". As we aid in this thread, cc:stable is a bit too much
automatic and sometimes not appropriate (not important enough fixes).
But when fixes not apparently suitable for stable are merged into
mainline, having the ability to spot them is useful, whether it is for
later inclusion or just for users who'd like to run a kernel with more
fixes than the critical ones accepted for stable.

> Don't add another tag that requires users to dig for fixes that we are
> just too lazy to be including for all users, that way is crazy.

I don't think so. If there is a gap between what is fixed and what is
acceptable for -stable, this just fills this gap. It means less automatic
submissions for -stable, only the important ones, and at the same time,
a simple way of more easily spotting if a known bug affects your kernel
when you're a -stable user and are experiencing an issue.

Willy

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ