[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161205130507.GH30758@dhcp22.suse.cz>
Date: Mon, 5 Dec 2016 14:05:08 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Stable tree <stable@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Willy Tarreau <w@....eu>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: [RFC PATCH] doc: change the way how the stable backport is
requested
On Mon 05-12-16 13:52:36, Greg KH wrote:
> On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@...e.com>
> >
> > Currently if a patch should aim a stable tree backport one should add
> >
> > Cc: stable@...r.kernel.org # $version
> >
> > to the s-o-b block. This has two major disadvantages a) it spams the
> > stable mailing list with patches which are just discussed and not merged
> > yet
>
> That's not a problem in that I know I like to see them to give me a
> "heads up" that something is coming down the pipeline soon.
Are you really tracking all those discussion to catch resulting patches
in the Linus' tree? I simply fail to see a point having N versions of
the patch on the stable mailing list before it gets picked up from the
_Linus'_ anyayw.
> I don't think anyone has ever complained of this before, do you?
This is the reason I have stopped following the stable mailing list.
The noise level is just too high.
> > and b) it is easy to make a mistake and disclose a patch via
> > git-send-email while it is still discussed under security embargo.
>
> Having this happen only once (maybe twice) in a over a decade really
> isn't that bad of odds. We have loads of embargoed security patches
> that properly include the cc: stable tag, yet don't leak the patch to
> the public mailing list. So this really is a rare thing to have happen.
Rare, still annoying and unnecessarily error prone. Btw. even git
send-email will not cope with Cc: stable # version properly... Here is
what I get when not using --suppress-cc=body on this particular patch
:From: Michal Hocko <mhocko@...nel.org>
:To: LKML <linux-kernel@...r.kernel.org>
:Cc: Michal Hocko <mhocko@...e.com>,
: stable@...r.kernel.org,
: #,
: $version
:Subject: [RFC PATCH] doc: change the way how the stable backport is requested
> (also when it did happen, no one except me seemed to notice it, which
> was pretty funny in itself...)
You can be pretty sure people have noticed even when not pointing that
out as a response to the particular email...
> > In fact it is not necessary to have the stable mailing list address in
> > the Cc until it hits the Linus tree and all we need is to have a
> > grepable marker for automatic identification of such a patch. Let's
> > use
> >
> > stable-request: $version[s]
> >
> > instead. Where $version would tell which stable trees might be
> > interested in the backport. This will make the process much less error
> > prone without any actual downsides.
>
> We still have whole subsystems that have yet to learn about how to put
> proper "cc: stable@..." in their patches, why do we want to change the
> muscle memory of those that are doing the right thing to now have to do
> something else?
I completely see this argument. It will take some time for people to
adapt any changes in the workflow. No question about that. I just
believe that a less error prone process would be more comfortable long
term. Making stable ML being only about stable related patches and the
follow up discussions sounds like an improvemnt to me as well.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists