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

Thorsten Leemhuis
2024-06-20T10:47:51Z

On 19.06.24 22:25, Laurent Pinchart wrote:
> 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 ?

Good point, but even if that training would exists it would be given by
someone that deciphered "a combination of unwritten rules, and written
documentation containing conflicting and partly outdated information"
(as well as posts from Linus about the topic found on lore). At least
unless we get Linus to give that training himself. :-)

Which is why I try to write something down and get it blessed -- ideally
by Linus, but if we a handful of core maintainers agree on it that good
enough for me as well.

> 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),

:-D

> but at best that provides partial knowledge of the expected maintenance
> process,

+1

> without even mentioning the issue of keeping the knowledge up
> to date.

Once written down a simple diff will take care of that -- ideally of
course coupled with some way to announcement the change to make people
aware of it.

But as I said somewhere else in this thread: writing things down has
downsides as well (misinterpretations/misunderstandings, situations
where ignoring them is for the greater good the right thing to do, ...).

> 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.

Ciao, Thorsten