Re: [MAINTAINERS SUMMIT] [4/4] Discuss how to better prevent backports of commits that turn out to cause regressions

[Thorsten Leemhuis <linux@leemhuis.info>]

On 13.06.24 15:40, Sasha Levin wrote:
> On Thu, Jun 13, 2024 at 10:42:01AM +0200, Thorsten Leemhuis wrote:
>> I would like to discuss how to better prevent backports of mainline
>> commits to stable that turn out to cause regressions.
> If you can tell us which backports cause regression we promise not to
> backport them :)

:)

FWIW (as you know, but others might not): I sometimes already do when I
notice such a problem (of course that only works if the regression is
tracked already). But the machinery and workflow for it could definitely
be improved on my side; it's on my todo list, but so are many other
things. :-/

>> * We could ask the stable team to only backport changes once they have
>> been in mainline for a certain time (something like "at the earliest two
>> weeks after the change was present in a mainline release or
> 
> We could, but is the net result positive? This also means that fixes for
> real issues take longer to get to users.

Well, if the fix is that important urgent it should have been merged in
the previous cycle and not have waited for the merge window.

> It would make sense if most backports cause a regression. Is it the
> case?

I can't answer that -- and the data I have is likely to incomplete for
that, as I don't become aware of all regressions.

>> pre-release"?). But to not delay urgent fixes we then would need
>> developers to mark the urgent ones somehow. That is likely a hard sell,
>> but maybe less so then what the previous point outlined; untangling
>> could help here, too.
> 
> I'd argue that even developers don't necessarily know if something is
> "urgent" or not. Heck, what does "urgent" mean? There are so many
> usecases for the kernel that it's impossible to define what is urgent
> and what is not.

Yup. :-/

>> * Maybe convince the stable team to consider all commits with just a
>> Fixes: tag as "non urgent", if they were merged during a merge window
>> with a committer (or author?) date from before the merge window -- and
>> then only backport them after -rc4 to ensure they got at least three
>> weeks of mainline testing before they are backported. This is imperfect
>> and has downsides, but would be relatively simple to realize.
> 
> The tricky part here is that we can't rely on stable tags for importance
> determination. Individuals and subsystems simply don't add stable tags
> because they don't want to, not because their commits are not important
> or urgent.

I know, I know. :-( That's why I introduced that section with "few
thoughts my brain came up with", as I myself was unsure how to best
improve the situation.

Ciao, Thorsten