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

Laurent Pinchart
2024-06-19T20:25:55Z

On Tue, Jun 18, 2024 at 02:58:38PM +0200, Thorsten Leemhuis wrote:
> 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.

This got me thinking: why don't we have trainings for maintainers,
instead of expecting people to decypher a combination of unwritten
rules, and written documentation containing conflicting and partly
outdated information ? Of course, the whole path going from a first
submission to the kernel to maintaining a subsystem is some sort of
training (even if it looks like the kind of epic training the hero
ninja/warrior/sorcerer will undergo on their perilous journey to saving
the kingdom more than a process designed to optimize the end result),
but at best that provides partial knowledge of the expected maintenance
process, without even mentioning the issue of keeping the knowledge up
to date. It sometimes feels we're discussing how to improve the process
without even considering that many people are not even aware there is a
process.

> 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 /
> https://docs.kernel.org/process/handling-regressions.html

--
Regards,

Laurent Pinchart