On 27.09.24 14:24, Christian Heusel wrote: > > I wondered a few times in the last months how we could properly track > regressions for the stable series, as I'm always a bit unsure how proper > use of regzbot would look for these cases. > > For issues that affect mainline usually just the commit itself is > specified with the relevant "#regzbot introduced: ..." invocation, but > how would one do this if the stable trees are also affected? Do we need > to specify "#regzbot introduced" for each backported version of the > upstream commit?! No, as there (most of the time, see below) is not much point in doing so (afaics!). And you'd need a separate mailing list thread or bugzilla ticket for each of them as well, which gets messy (but might be worth it for cases like the "[0]" you linked to!). To explain the current state of things: Usually when a regression affects multiple stable series it also happens in mainline. Then it should just be tracked it as mainline regression, as Greg almost always will wait for the fix to hit mainline anyway -- and then usually will backport the fix on his own, as long as it has a fixes tag. Sooner or later this ideally should be improved with additional features in regzbot: * A way to tell regzbot "this mainline regression does not affect the following stable series" (they usually do, so coming from the negative side of things is likely the right thing). * The webui on the page for stable kernels should list all mainline regressions that affect stable series as well, because the culprit was backported to them (unless they were marked to not happen there, see previous point) -- and should continue to do so until the mainlined fix lands in those stable series as well. One case then afaics remains uncovered: regressions that happen in more than one stable series, but not in mainline (for example because some per-requisite is missing in all of those series). Not sure, some way to tell regzbot "this affects multiple stable series" is likely the right slution for that. In the end all of that should not be really simple to implement, but not hard either -- but well, due to lack of funding development currently is mostly stopped. :-/ Hopefully things will improve soon again. But even then there are imho more important features that need to be addressed first. :-/ > IMO this is especially interesting because sometimes getting a patchset > to fix the older trees can take quite some time since possibly backport > dependencies have to be found or even custom patches need to be written, > as it i.e. was the case [here][0]. The above should hand this case afaics. If not, please let me know. > This led to fixes for the linux-6.1.y > branch landing a bit later which would be good to track with regzbot so > it does not fall through the cracks. > > Maybe there already is a regzbot facility to do this that I have just > missed, but I thought if there is people on the lists will know :) The idea to handle stable better is pretty much in my head sind regzbot's early days, but you know how it is: there only so many hours in a day. > P.S.: I hope everybody had a great time at the conferences! I hope to > also make it next year .. FWIW, sounds that will require and intercontinental flight next year. :-/ But fwiw, a few people consider doing a kernel track at CLT oder Frosscon next year; and next year I might go to Kernel Recipes again is the timing is better. > [0]: https://lore.kernel.org/all/66bcb6f68172f_adbf529471@xxxxxxxxxxxxxxxxxxxxxx.notmuch/ HTH, ciao, Thorsten
