Re: Time from regression report to a merge of a fix (was Re: [git pull] drm fixes for 7.0-rc1)

[Thorsten Leemhuis]

On 2/24/26 08:05, Dave Airlie wrote:
> On Tue, 24 Feb 2026 at 16:50, Dave Airlie <airlied@xxxxxxxxx> wrote:
>> On Mon, 23 Feb 2026 at 22:52, Thorsten Leemhuis
>> <regressions@xxxxxxxxxxxxx> wrote:
>>> On 2/20/26 21:53, Dave Airlie wrote:
>>>
>>> * One fix in here was for a amdgpu regression introduced in v6.19-rc6
>>> (and also affecting many stable series due to backports). The fix was
>>> ready within ~2 days and could even have made v6.19 -- but it only
>>> reached mainline through this PR on Friday. IOW: After two weeks. Which
>>> got me wondering, "Should we do something to merge fixes like that
>>> faster"? And yes, it's the merge window – but that's also when Arch
>>> Linux and openSUSE Tumbleweed usually jump to the latest mainline series
>>> and thus expose regressions like this to many users, so I guess it would
>>> be good to get them fixed at least as fast as outside of merge windows.
> 
> I think due to the patch pipeline depth and volume that amdgpu and
> i915/xe are dealing with we may need to consider some better
> regression revert pipelines,

Thx for your reply. And also for considering adjustments.

> The amdgpu one definitely should have been fixed in 6.19, Alex any
> idea how we can alleviate that sort of problem, 

FWIW, I see situations like these in various subsystems, and I think
there are two important factors at play here:

* The more important one: Some maintainers refrain from quickly picking
up and sending fixes upwards during merge windows, as they fear getting
yelled at by higher-level maintainers or Linus if those cause problems.

  And I can understand that, as Linus for good reasons has gotten quite
unhappy in the past when a big merge window PR contained late changes,
especially if those then caused things like build errors -- except when
the PR had stated explicitly that those were last-minute regression fixes.

  In fact, one lower-level maintainer in the arm64 dts space just told
me in private that this was one reason why he only picked up a revert
fixing a 6.18-rc1 regression yesterday after it sat on the list for
nearly two weeks.

* Some maintainers refrain from sending regression fixes upwards right
before a new mainline release, as they fear breaking something
important. Considering that outcome, of course, is something that must
be done, but it feels to me like many are a way more careful there then
Linus would like -- and forget that they could just send the last-minute
fixes to him to make him decide, as he is in the best position to do so,
as he when needed then could even delay the release.

Not sure how to improve all of this. Maybe some announcement from Linus
along the following lines would help:

"An open merge window should not delay picking up and upstreaming
regression fixes in any way; if needed, keep your fixes branch running
as before the release and send separate PRs for them. And as usual,
don't worry about conflicts unless they are complex. Ohh, and if you
have regression fixes where you are unsure if it is worth merging them
right before a new release, send them to me and let me decide".

Ciao, Thorsten