Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Greg KH]

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

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

> > 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 :)

thanks,

greg k-h