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

[Jani Nikula <jani.nikula@linux.intel.com>]

On Tue, 24 Feb 2026, Dave Airlie <airlied@gmail.com> wrote:
> On Tue, 24 Feb 2026 at 16:50, Dave Airlie <airlied@gmail.com> wrote:
>>
>> On Mon, 23 Feb 2026 at 22:52, Thorsten Leemhuis
>> <regressions@leemhuis.info> wrote:
>> > * One fix in here was for a i915/xe regression introduced in v6.18-rc1.
>> > Once reported, it took about six weeks to get fixed – and then nearly 10
>> > days for the fix to reach mainline. Looking at this, I once more
>> > wondered if this could have been merged faster. But even more I wondered
>> > why the culprit wasn't reverted, as that's what Linus afaics wants when
>> > it takes this long.
>
> I think for the i915 one the problem patch should have been reverted
> asap, but I just don't think there was a responsible person to do it,
> maintainers need to be in the loop for these sort of problems, but if
> they aren't in the loop and the regression sits in the bug tracker
> without them being looped on it, we rely on the reporter or developer
> to find it and do the right thing. Esp when developers are head down
> on fixing it, but then it doesn't get flagged as urgent once it goes
> into the -next pipeline and so on. We don't usually break the weekly
> fixes cycles for drm, because CI backlogs and other things it just
> fits nicely, if we do have regressions like this it might be that we
> need to start having urgent PRs out of cycle, which I don't object to,
> it's just a matter of whether maintainers can have this sort of
> insight into patches in the pipeline when there is quite a long
> backlog.

I think it's pretty natural for developers to err on the side of trying
to fix things instead of reverting, and the responsibility to make the
call to revert usually lands on maintainers.

I'll remind people about considering reverts earlier if the fix isn't
obvious, and looping in maintainers when in doubt.

As to the 10 days from fix to mainline, it's down to unfortunate
timing. The fix landed right after the v6.19 release during the merge
window. It was part of the drm pull request for v7.0-rc1. There's no
faster path at that time.

BR,
Jani.

-- 
Jani Nikula, Intel