On 04.04.24 17:44, Greg KH wrote: > On Thu, Apr 04, 2024 at 05:36:42PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote: >> 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] > > We do this today, with stuff like: > Cc: stable <stable@xxxxxxxxxx> # wait for -rc3 to be out > > So if people want to do that, they can, the documentation says that you > can give us hints and the like in the # area, and usually we notice them :) I know, as I wrote that (as you likely remember). ;-) But it seems it's not well known; and maybe making it explicit that this can be used to convey a "DoNotBackport" message is supported as well. Guess I'll prepare a patch to do that then and we'll see how it goes from there. Ciao, Thorsten
