From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:52964 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750951AbcLEN6S (ORCPT ); Mon, 5 Dec 2016 08:58:18 -0500 Date: Mon, 5 Dec 2016 14:58:24 +0100 From: Greg KH To: Michal Hocko Cc: LKML , Stable tree , Andy Lutomirski , Willy Tarreau , Jiri Kosina Subject: Re: [RFC PATCH] doc: change the way how the stable backport is requested Message-ID: <20161205135824.GA30013@kroah.com> References: <20161205072154.8177-1-mhocko@kernel.org> <20161205125236.GA19696@kroah.com> <20161205130507.GH30758@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161205130507.GH30758@dhcp22.suse.cz> Sender: stable-owner@vger.kernel.org List-ID: On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > 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 > > > > > > 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. > > 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 do scan them, sometimes I even find problems with them (like a zram "fix" that went by this weekend.) So yes, it is always good to have more reviewers on patches, don't you think? > > 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. What "noise"? It's all patches that are being addressed to the stable kernels, how is that off-topic? What do you expect to be posted to this list? > > > 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 > :To: LKML > :Cc: Michal Hocko , > : stable@vger.kernel.org, > : #, > : $version > :Subject: [RFC PATCH] doc: change the way how the stable backport is requested People are working on the "# 4.4+" issue in git right now, there was a thread about it last week. > > > 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. But the stable ML is only about stable related patches today, how would that change? thanks, greg k-h