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. 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 -- 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