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: > > 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? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
