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 :) thanks, greg k-h
