Re: [MAINTAINERS SUMMIT] [3/4] Elevate handling of regressions that made it to releases deemed for end users

Thorsten Leemhuis
2024-06-18T12:58:51Z

On 14.06.24 16:10, Mark Brown wrote:
> On Thu, Jun 13, 2024 at 01:39:00PM +0200, Jiri Kosina wrote:
>> On Thu, 13 Jun 2024, Laurent Pinchart wrote:
>
>>> I don't think piling pressure will help. What could help is to reduce
>>> pressure on already overloaded maintainers, to give them more time to
>>> handle regressions. There have been multiple discussions about
>>> co-maintainance models over the past few years, and some subsystems are
>>> (slowly) moving forward. I would be more interested in participating in
>>> that effort.
>
>> Fully agreed. That's exactly why a few days ago I proposed the topic about
>> exploring the options of making the merge tree more deep (by delegating
>> more and making the co-maintainership model more prominent), as that in my
>> view is the only available solution to the current maintainer pressure
>> problem.
>
> In my experience deeper maintainer trees are often a factor in slowing
> down patches, passing things between maintainers often just inherently
> adds delays even if nobody goes on holiday or whatever.

From what I see from the regressions perspective they are not ideal
either. The slow down is one problem, unless the process is streamlined
well. Another one from my biased point of view seems to be that a few of
are far away from Linus and apparently not fully aware how he wants
regressions to be handled.

Which is not really surprising, as over the years there were quite a few
cases where maintainers of core subsystems were not handled well either.
But sooner or later that resulted in a clash with Linus[1] and from then
on things worked better. For many sub-subsystem something like that
never happened -- and the maintainers of the higher level subsystem can
not have their eyes everywhere, so they do not notice such problems or
are more lax and friendly.

If I notice a regression is not handled well in a sub-subsystem I point
it out (often in private) to the higher level maintainers. But that does
it tedious, does not scale, and delays things. That's one of the reasons
why written guidelines IMHO would be worth it.

Ciao, Thorsten

[1] see the quotes from Linus at the end of
Documentation/process/handling-regressions.rst /