[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161205143915.GN30758@dhcp22.suse.cz>
Date: Mon, 5 Dec 2016 15:39:15 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Stable tree <stable@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Willy Tarreau <w@....eu>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: [RFC PATCH] doc: change the way how the stable backport is
requested
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 <mhocko@...e.com>
> > > > > >
> > > > > > Currently if a patch should aim a stable tree backport one should add
> > > > > >
> > > > > > Cc: stable@...r.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?
> 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?
> 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.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists