On 3/28/26 14:37, Salvatore Bonaccorso wrote: > > Bernd Schumacher reported in Debian (report and report from bisection > in https://bugs.debian.org/1131025) a 6.12.y specific regression of > 58130e7ce6cb ("PCI/ERR: Ensure error recoverability at all times"):
TWIMC, "6.12.y specific" seems to be really the case here, to quote from https://bugs.debian.org/1131025: ""Installing linux-{image,modules,base,binary}-6.19.8+deb14-amd64_6.19.8-1_amd64.deb and booting 6.19.8+deb14-amd64 (6.19.8-1) works without the described issues."" > Anything else we can provide to identify the issue present in 6.12.y > kernels? First: many thx for forwarding this regression and a lot of others similarly in the past; it's great. There is one thing that could make them a lot better: if you always make it unmistakably obvious (ideally at the top of the mail) if mainline is affected or not (here it was close, yes, but sadly some people write "specific" without ever testing mainline, so it was not unmistakably :-/ ). Overall, it IMHO is best to keep this mental model: mainline and stable/longterm series are maintained by different people -- and those from one group do not care about the regressions the other party has to handle. In practice it's of course way more nuanced: for example, many (but not all!) mainline developers help the stable team out somewhat, and some of them might even handle regression reports with longterm kernels; and the members of the stable team are mainline developers as well, so when a bug falls into their domain, it might not be important. But to avoid delays or things falling through the cracks, it's really best to always check if mainline is affected – and report regressions like a mainline problem using a mainline version if they are and leave the stable team out of it, as they most likely will leave things to the mainline developers. And if it's stable-specific regression, state early that mainline is not affected. Ciao, Thorsten
