Message-ID: <20130713182717.GA16637@kroah.com>
Date:	Sat, 13 Jul 2013 11:27:17 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Theodore Ts'o <tytso@....edu>, Willy Tarreau <w@....eu>,
	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 Sat, Jul 13, 2013 at 07:42:11AM -0400, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 11:48:01PM -0700, Greg Kroah-Hartman wrote:
> > > 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).
> > 
> > No, I've never said that.
> 
> You've not said this, but Linus has.  Linus has pointed at the
> following words which are in stable_kernel_rules:
> 
>  - 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.                                             ^^^^^^^^^^^^^^^^^^^
>    ^^^^^^^^

Ugh, the conversation has degenerated now into parsing the meaning of
specific words.  This is why lawyers have created whole vocabularies
that are not used by "normal" people.  There's a very good reason why
I'm not a lawyer, and this is one of them...

If I change the word "critical" to "real", would that make everyone
happy here?

It comes down to the simple fact that for stable kernels I _want_ to
take bugfixes that any user would hit.  In other words, something that a
distro kernel would take.

And, I'll throw up the famous "I know it when I see it", definition of
what a valid fix is, to keep people from "word parsing" the exact way to
write it all down.

It's a grey area, which is good, let's keep it that way.

And again, that's not the real problem here.  The real problem is that
people are keeping valid "fixes" out of the .0 kernel for some odd
reason.

So here's what I'm going to do.  I'm going to go through all of my
pending stable patches in the next few days, discarding anything that
remotely "hints"[1] that it should have been pushed to Linus for .0.

Then I'll notify those maintainers, and make them resend the patches,
and explain _why_ they held off sending them, if they really want them
in the stable releases.

That should hopefully start to notify maintainers that they need to step
up and send stuff to Linus earlier, or they can justify why they didn't
send them at the time (which is fine, I know I think I have valid
reasons for why I didn't send some of my -stable patches in for the .0
release.)

I'll start digging through linux-next about -rc4 timeframe and watch for
stable tags to show up, and start pestering people about why they are
there and not in Linus's tree.

And then let's see what happens for 3.11.0, and the 3.12-rc1 merge
window.  If nothing's changed by then compared to this flood we got for
3.11-rc1, then we can revisit it then.

Yes, this is going to require more work on my behalf for the next few
months, but what else was I going to do with my summer, actually enjoy
the weather?...

Sound ok with everyone?

greg k-h

[1] A big hint is the date of the patch being a month or so before .0
    was released.  I'll point to the powerpc mess as an example of
    that...
--
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