On Mon, Apr 16, 2018 at 12:53:07PM -0400, Steven Rostedt wrote:
On Mon, 16 Apr 2018 16:43:13 +0000 Sasha Levin Alexander.Levin@microsoft.com wrote:
If you are worried about people not putting enough "Stable: " tags in their commits, perhaps you can write them emails "hey, I think this should go to stable, do you agree"? You should get people marking their commits themselves pretty quickly...
Greg has been doing this for years, ask him how that worked out for him.
Then he shouldn't pull in the fix. Let it be broken. As soon as someone complains about it being broken, then bug the maintainer again. "Hey, this is broken in 4.x, and this looks like the fix for it. Do you agree?"
If that process would work, I would also get ACK/NACK on every AUTOSEL request I'm sending.
What usually happens with customer reported issues is that either they're just told to upgrade to the latest kernel (where the bug is fixed), or if the distro team can't get them to do that and go hunting for that bug, they'll just pick it for their kernel tree without ever telling -stable.
I had a project to get all the fixes Cannonical had in their trees that we're not in -stable. We're talking hundreds of patches here.
I agree that some patches don't need this discussion. Things that are obvious. Off-by-one and stack-overflow and other bugs like that. Or another common bug is error paths that don't release locks. These should just be backported. But subtle fixes like this thread should default to (not backport unless someones complains or the author/maintainer acks it).
Let's play a "be the -stable maintainer" game. Would you take any of the following commits?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/comm... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/comm... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/comm...