From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752021AbcLEO5G (ORCPT ); Mon, 5 Dec 2016 09:57:06 -0500 Received: from mail-wj0-f195.google.com ([209.85.210.195]:33981 "EHLO mail-wj0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751492AbcLEO4w (ORCPT ); Mon, 5 Dec 2016 09:56:52 -0500 Date: Mon, 5 Dec 2016 15:56:25 +0100 From: Michal Hocko To: Greg KH 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: <20161205145625.GI30765@dhcp22.suse.cz> References: <20161205072154.8177-1-mhocko@kernel.org> <20161205125236.GA19696@kroah.com> <20161205130507.GH30758@dhcp22.suse.cz> <20161205135824.GA30013@kroah.com> <20161205141451.GK30758@dhcp22.suse.cz> <20161205142137.GA4332@kroah.com> <20161205143915.GN30758@dhcp22.suse.cz> <20161205144359.GA7683@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161205144359.GA7683@kroah.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 05-12-16 15:43:59, Greg KH wrote: > On Mon, Dec 05, 2016 at 03:39:15PM +0100, Michal Hocko wrote: > > On Mon 05-12-16 15:21:37, Greg KH wrote: > > > On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote: > > > > On Mon 05-12-16 14:58:24, Greg KH wrote: > > > > > 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? > > > > > > > > Yes I do agree that more review is better. But then the stable mailing > > > > list is a complete failure in that resopect - at least for me. Why? > > > > Simply because it doesn't contain discussion for the stable inclusion > > > > but rather something that eventually might happen to become stable > > > > material. This what I call noise and the reason why I've stopped > > > > following the stable ML. > > > > > > That doesn't make sense, I want to see patches that are being proposed > > > for the stable kernels _before_ they get into the maintainers and > > > Linus's tree, as then, it is almost always too late. > > > > Too late for what? I am still not sure I see your point. Are you > > suggesting that a review from the stable mailing list, which wouldn't > > be a part of a standard review process normally, has helped to identify > > issues? > > Sometimes, yes, this happens. It is really hard to argue here... But effectivelly something is really broken when wrong/unsuitable patches marked for stable pass the maintainer. > > > I will point out the zram patch this weekend as an example of that, > > > where if the original had gone in, it would be a while before the > > > "fixup" would have then gone in, and the abi deprecation would probably > > > have missed 4.11 entirely. > > > > I do not have a full context here. Do you have a pointer please? > > A patch for the zram subsystem was cc: stable this weekend and I pointed > out problems with it and the user/kernel api that it was modifying. I > would have never seen this patch otherwise. I guess you are talking about https://lkml.org/lkml/2016/12/3/257? If yes then the patch hasn't even been taken by Andrew so I am wondering why do mention it as a hand break coming from the stable tree. > > > Don't you want to catch things earlier rather than later? > > > > Sure, but I fail to see the role of the stable ML in this area. I might > > be underastimating its role of course. > > I think you are :) > > Seeing the patches sent to the list _before_ they end up in a > maintainers tree, or Linus's tree, helps some issues to be resolved. > Most of the time it just lets me know what to watch out for, and what > areas of the kernel are having lots of issues. > > Given that the current maintainers of the stable kernels don't seem to > be objecting to the current setup of this list, I find it odd that you > wish to change it :) The reason I came up with this is simple and I have mentioned that in the changelog. I just thought we might improve the process a bit, if there is no demand for that then I will not push for it. This is an RFC after all. -- Michal Hocko SUSE Labs