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 <mhocko@xxxxxxxx> > > > > > > Currently if a patch should aim a stable tree backport one should add > > > > > > Cc: stable@xxxxxxxxxxxxxxx # $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 <mhocko@xxxxxxxxxx> > :To: LKML <linux-kernel@xxxxxxxxxxxxxxx> > :Cc: Michal Hocko <mhocko@xxxxxxxx>, > : stable@xxxxxxxxxxxxxxx, > : #, > : $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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html