[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1373845958.19894.320.camel@pasglop>
Date: Mon, 15 Jul 2013 09:52:38 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Guenter Roeck <linux@...ck-us.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
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, 2013-07-12 at 10:50 -0700, Linus Torvalds wrote:
> You cut out the important part:
>
> - It must fix a problem that causes a build error (but not for things
> marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> security issue, or some "oh, that's not good" issue. In short, something
> critical.
>
> That list is not a "or" list, it's an "and" list - it needs to follow
> *all* the rules. The exception is the "New device IDs and quirks are
> also accepted", which maybe should be made more clearly separate.
So if I read this (and stable_kernel_rules.txt) correctly, that means that
for example, let's say, we find in RHEL66 or SLES42 (possibly following
a user report), for example, that PCI hotplug is broken with some category
of devices on some machines.
We do a fix, it's roughtly 4 or 5 lines, pretty self contained. We get it
into the distro.
That still doesn't qualify for stable right ? We have to start shooting at
every distro around separately or wait for users of those other distros
to also hit it ?
Where is the line when something "Doesn't work" (without crashing/oops'ing or
being a security issue) ?
My personal line so far has been to take it and send it to -stable if the
patch is simple enough and self contained (little risk of side effects).
But I can stop if that's indeed the accepted rule.
Cheers,
Ben.
--
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