From: Greg KH <gregkh@linuxfoundation.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Stable tree <stable@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>, Willy Tarreau <w@1wt.eu>,
Jiri Kosina <jkosina@suse.cz>, Michal Hocko <mhocko@suse.com>
Subject: Re: [RFC PATCH] doc: change the way how the stable backport is requested
Date: Mon, 5 Dec 2016 13:52:36 +0100 [thread overview]
Message-ID: <20161205125236.GA19696@kroah.com> (raw)
In-Reply-To: <20161205072154.8177-1-mhocko@kernel.org>
On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> Currently if a patch should aim a stable tree backport one should add
>
> Cc: stable@vger.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. I don't
think anyone has ever complained of this before, do you?
> 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.
(also when it did happen, no one except me seemed to notice it, which
was pretty funny in itself...)
> 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?
So I don't think we need this change, let's just keep things as they
are. If more and more people get sloppy and mess up, we can revisit it
then.
thanks,
greg k-h
next prev parent reply other threads:[~2016-12-05 12:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-05 7:21 [RFC PATCH] doc: change the way how the stable backport is requested Michal Hocko
2016-12-05 12:52 ` Greg KH [this message]
2016-12-05 13:05 ` Michal Hocko
2016-12-05 13:15 ` Willy Tarreau
2016-12-05 13:24 ` Michal Hocko
2016-12-05 13:30 ` Willy Tarreau
2016-12-05 13:58 ` Greg KH
2016-12-05 14:14 ` Michal Hocko
2016-12-05 14:21 ` Greg KH
2016-12-05 14:39 ` Michal Hocko
2016-12-05 14:43 ` Greg KH
2016-12-05 14:56 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161205125236.GA19696@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=stable@vger.kernel.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox