[CCing Jakub, Greg and the regressions list] On 19.04.23 06:54, Kalle Valo wrote: > Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > >>>> Anyway, cf the bugzilla [FWIW, it's this ticket Toke meant: https://bugzilla.kernel.org/show_bug.cgi?id=217286 ] >>>> this was a pretty bad regression for 6.2, so >>>> would be good to move this along reasonably quickly (although I guess we >>>> just missed the -net PR for rc7)... >>> >>> I'm not planning to send anymore stuff to v6.3 so my plan is to take >>> this to -next. The merge window is very close anyway so this shouldn't >>> cause too much delay. >> >> Hmm, okay, a bit unfortunate that we'll ship 6.3 with the same bug > > Yeah, it is unfortunate. Agreed. > But it is always a question of time :) To save > time I usually try to send two wireless tree pull requests per cycle, > one early in the cycle and the second around the middle. Why not ask Linus to pull this directly from the list then? He doesn't mind doing that for an occasional regression fix. And then he can decide himself if the change is worth the risk -- and obviously can take into account if he'll release and rc8 or not. That's why Documentation/process/handling-regressions.rst (https://docs.kernel.org/process/handling-regressions.html ) even tells people to use that approach in a situation like this one. Fun fact: that document also says "Subsystem maintainers are expected to assist in reaching those periods [...]. They thus might have to send git-pull requests earlier or more often than usual; [...]". That whole section has a lot of "Ideally" in it, because yes, this thing called real life is complicated sometimes and we are all volunteers. But still it's a bit unfortunate that such a important tree like wireless doesn't sent its fixes upstream every week. > The patch has cc stable so I assume it should go quickly to stable > releases. To me it looks a lot like Greg most of the time only backports important bug fixes during merge windows (e.g. when asked or when he noticed something important) -- and leaves everything else often until after rc1. And when there are a lot of backports, he might even do it in two batches then. Hence it might easily take until ~May 11th or 18th (if we get a rc8) until this fix reaches 6.2.y and 6.3.y. Then it in the end would have taken about one month for the fix to reach the users. That is really unfortunate. Preventing such situations (which are not rare) is one of the main reason why handling-regressions.rst was written like it is... Ciao, Thorsten
