linux-kernel - Re: [ 00/19] 3.10.1-stable review

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]

Message-ID: <20130713062223.GA15155@kroah.com>
Date:	Fri, 12 Jul 2013 23:22:23 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Willy Tarreau <w@....eu>
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 09:50:51PM +0200, Willy Tarreau wrote:
> On Fri, Jul 12, 2013 at 10:50:08AM -0700, Linus Torvalds wrote:
> > So I'm not going to argue that your particular patches were the
> > problem here. I'm more arguing against your arguments than against the
> > patches themselves. I'm not looking for some hard black-and-white
> > rules that say "this is exactly how things have to work", because I
> > don't think such rules can exist. But I _do_ want people to see the
> > stable rules as fairly strict.
> 
> I think that maintainers are balanced between the wish to satisfy their
> users and the risk of getting shouted at. Users expect stable versions
> to be bug-free. Most people I talk with have a different understanding
> of the development model than the one you present to contributors. They
> think that the .0 release is a draft and that all bugs will be fixed in
> -stable. I even know one person who uses -rc1 in production, claiming
> that these ones are stable. So end users don't necessarily understand
> the development model and ask what something they think is due : no
> known bugs.
> 
> On the other hand, we've seen many regressions introduced as fixes
> into -stable that had to be reverted afterwards, or sometimes
> completed with a missing patch.
> 
> I think that maintainers use the Cc:stable as a status for commits
> meaning "this is a bug fix". It's true that when you're digging into
> the commits to try to qualify fixes from features, it's really hard,
> and the new Cc:stable tag helps a lot.
> 
> 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.

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.

greg k-h
--
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/