On 03.04.24 18:10, Greg KH wrote: > On Wed, Apr 03, 2024 at 05:22:17AM -1000, Tejun Heo wrote: >> On Wed, Apr 03, 2024 at 07:11:04AM +0200, Greg KH wrote: >>>> Side note: I have no idea why the stable team backported those patches >>>> and no option on whether that was wise, just trying to help finding the best >>>> solution forward from the current state of things. >>> >>> The Fixes: tag triggered it, that's why they were backported. Yeah, this is what I assumed. >>>>> which would >>>>> be far too invasive for -stable, thus no Cc: stable. >>>>> >>>>> I didn't know a Fixes >>>>> tag automatically triggers backport to -stable. I will keep that in mind for >>>>> future. >>>> >>>> /me fears that more and more developers due to situations like this will >>>> avoid Fixes: tags and wonders what consequences that might have for the >>>> kernel as a whole >>> >>> The problem is that we have subsystems that only use Fixes: and not cc: >>> stable which is why we need to pick these up as well. Fixes: is great, >>> but if everyone were to do this "properly" then we wouldn't need to pick >>> these other ones up, but instead, it's about 1/3 of our volume :( I'm also well aware of that and do not want to complain about it, as I think I grasped why the stable team works like that -- and even think given the circumstances it is round about the right approach. I also understand that mistakes will always happen. Nevertheless this thread and the Bluetooth thing we had earlier this week[1] makes me fear that this approach could lead to developer avoiding Fixes: tags. And funny thing, that's something that is already happening, as I noticed by chance today: "'"A "Fixes" tag has been deliberately omitted to avoid potential test failures and subsequent regression issues that could arise from backporting."'"[2]. I wonder if that in the long term might be bad. But well, maybe it won't matter much. Still made me wonder if we should have a different solution for this kind of problem. Something like this? Cc: <stable@xxxxxxxxxxxxxxx> # DoNotBackport Or something like this? Cc: <stable@xxxxxxxxxxxxxxx> # DoNotBackport - or only after 16 weeks in mainline [but I don't care] Whatever, mainly thinking aloud and do no need a reply to this. :-D [1] https://lore.kernel.org/all/84da1f26-0457-451c-b4fd-128cb9bd860d@xxxxxxxxxxxxx/ [2] saw that today here: https://lore.kernel.org/all/cover.1712226175.git.antony.antony@xxxxxxxxxxx/ >>> I'll gladly revert the above series if they shouldn't have been >>> backported to stable, but from reading them, it seemed like they were >>> fixing an issue that was serious and should have been added to stable, >>> which is why they were. >> Oh, yeah, they're fixing an issue. It's just that the issue is relatively >> confined peformance degradation and the fix is really invasive, so not a >> great -stable candidate. At the very least, they'd need a log longer cooking >> time in mainline before being considered for -stable backport. > Ok, I'll go revert them all now. I did some test builds here with them > reverted and they seem sane. I'll push out some -rcs with just the > reverts to at least fix the regressions found in the 6.8.y tree now. Great, thx for taking care of this! Ciao, Thorsten
