On Tue, Apr 24, 2018 at 11:13:25PM +0200, Hans de Goede wrote:
FWIW this has gotten into 4.15 without it having a Cc: stable or a Fixes: tag, I think it was picked up by the new magic scripts scripts which try to find commits which should have a Cc: stable but are lacking one.
In this case I deliberately did not add a Cc: stable as what gets fixed is not that important, whereas the possible regression this might cause (and actually seems to be causing) is sorta bad.
This isn't the first time I've seen patches backported that simply don't need to be, or shouldn't be. In one case a few years back the patch had a fixes tag, but it still wasn't important to backport, which is why I left off the Cc stable, and in fact it broke something.
TBH its a bit distracting having to review such patches, which I've already looked at before, determined there's no need for a backport, and subsequently paged out of my head.
Stable folk: is there already (and should there be) a defined mechanism to record that a given patch is:
1) not suitable/worthwhile to backport (e.g. even though it might have a Fixes tag or use the word "fix").
2) OR it would require a bit more human effort to backport (perhaps it applies cleanly but would be expected not to build/work) and probably shouldn't be attempted automatically.
3) OR it probably isn't worth backporting and is risky to do so, and so should only be carefully attempted if somebody actually complains.
other than simply stating it in prose in the commit message?
Cheers James
On Tue, Apr 24, 2018 at 10:50:48PM +0100, James Hogan wrote:
On Tue, Apr 24, 2018 at 11:13:25PM +0200, Hans de Goede wrote:
FWIW this has gotten into 4.15 without it having a Cc: stable or a Fixes: tag, I think it was picked up by the new magic scripts scripts which try to find commits which should have a Cc: stable but are lacking one.
In this case I deliberately did not add a Cc: stable as what gets fixed is not that important, whereas the possible regression this might cause (and actually seems to be causing) is sorta bad.
This isn't the first time I've seen patches backported that simply don't need to be, or shouldn't be. In one case a few years back the patch had a fixes tag, but it still wasn't important to backport, which is why I left off the Cc stable, and in fact it broke something.
TBH its a bit distracting having to review such patches, which I've already looked at before, determined there's no need for a backport, and subsequently paged out of my head.
Stable folk: is there already (and should there be) a defined mechanism to record that a given patch is:
not suitable/worthwhile to backport (e.g. even though it might have a Fixes tag or use the word "fix").
OR it would require a bit more human effort to backport (perhaps it applies cleanly but would be expected not to build/work) and probably shouldn't be attempted automatically.
OR it probably isn't worth backporting and is risky to do so, and so should only be carefully attempted if somebody actually complains.
other than simply stating it in prose in the commit message?
Just say in the changelog "this should not go to stable kernels because of X, Y, and Z". We read them by hand, and I can easily drop the patch because of that.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
James Hogan