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