[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180504174055.GF4649@kroah.com>
Date: Fri, 4 May 2018 10:40:55 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: "Theodore Y. Ts'o" <tytso@....edu>,
Jani Nikula <jani.nikula@...el.com>,
David Howells <dhowells@...hat.com>,
Sasha Levin <Alexander.Levin@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ksummit-discuss@...ts.linuxfoundation.org"
<ksummit-discuss@...ts.linuxfoundation.org>, "w@....eu" <w@....eu>
Subject: Re: [Ksummit-discuss] bug-introducing patches
On Fri, May 04, 2018 at 09:09:32AM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 04, 2018 at 03:31:17PM +0300, Jani Nikula wrote:
> > On Fri, 04 May 2018, David Howells <dhowells@...hat.com> wrote:
> > > Sasha Levin via Ksummit-discuss wrote:
> > >
> > >> Cc: stable@...r.kernel.org # commit-id-of-(2)
> >
> > This has been documented since
> >
> > commit 8e9b9362266dd16255473c080d846b13e27247bf
> > Author: Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
> > Date: Sun Dec 6 12:24:31 2009 +0100
> >
> > Doc/stable rules: add new cherry-pick logic
> >
> > in v2.6.33 so seems like there should have been enough time to fix the
> > tools.
>
> The problem is that it's not being *used* that way. In fact, that
> documentation is arguably out of date. When it does get used, it's
> used to indicate which kernels the stable patch applies. You have to
> go pretty far back before you find that suggested usage. Run:
>
> git log --grep stable@...nel.org | grep -i cc: | grep stable | grep \#
>
> and see for yourself. The first couple of hits:
>
> Cc: stable@...nel.org # 3.11
> Cc: stable@...nel.org # 4.8+
> Cc: stable@...nel.org # 4.8+
> Cc: stable@...nel.org # 4.13+
> Cc: stable@...nel.org # 4.8+
> Cc: stable@...nel.org # 4.13 - together with 890da9cf0983
> Cc: stable@...nel.org # 4.13
> Cc: stable@...nel.org # 4.13
> Cc: stable@...nel.org # v4.8+
> Cc: stable@...nel.org # v4.10+
> Cc: stable@...nel.org # v4.10+
> Cc: stable@...nel.org # v4.10+
> Cc: stable@...nel.org # reverted commits were marked for stable
> Cc: stable@...nel.org # for the backport of the original commit
> Cc: stable@...nel.org # v4.8+
>
> At this point, my suggestion would be to delete the text added by the
> above-mentioned commit, and add a new syntax. We're much more willing
> to support multiple headers, so something like this:
>
> Stable-prereq: DEADBEEF1234: subsystem: bork bork bork....
>
> With multiple Stable-preeq: lines allowed, where the order is
> significant, might be one way to do things.
Ugh, what? I don't understand what you are proposing here, what we have
today is just fine, what is broken with it?
thanks,
greg k-h
Powered by blists - more mailing lists