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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.