Re: [PATCH] RFC: add MAINTAINERS file

From: Linus Arver <linusa@google.com>
Date: Mar 27, 2024, 04:32 UTC
Message-ID: <owly7cho1eh4.fsf@fine.c.googlers.com>
In-Reply-To: <xmqqsf0gvjrg.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 27 quoted lines

> "Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Linus Arver <linusa@google.com>
>>
>> This patch is designed to spur discussion about adding an official
>> MAINTAINERS file to our project. The hope is that it could be used as a
>> reference in (at least) the following scenarios:
>>
>>   (1) [CC list] patch authors want to know who to CC on their
>>       submissions, without resorting to git-blame-level of precision;
>>
>>   (2) [escalation path] patch authors have been waiting 1+ weeks for
>>       review comments, but are not sure who to escalate to (other than
>>       Junio);
>>
>>   (3) [status tracking] record former maintainers/reviewers who are now
>>       inactive.
>>
>> In addition having a MAINTAINERS file could give a more official sense
>> of ownership in the codebase.
>
> OK.  They are understandable goals.
>
> As to the format of the actual file, I do not have much opinion.
> What works for the kernel may or may not work for us, as the project
> size is very different, but I am fairly confident that we can agree
> on something usable.

Agreed.

Show 17 quoted lines

> I am more worried about how the file is used and maintained.  Some
> things to think about while in the "spurred discussion" I can think
> of are:
>
>  - Is the project big enough to require this (especially for the
>    purpose of (1)), or would
>
>    $ git shortlog -n --no-merges --since=24.months -- path-to-file
>
>    be sufficient and more importantly the value that it will keep
>    current automatically outweigh the benefit of having this file
>    that can go stale?
>
>    To answer this question, we'd need to know
>    the turnover rates of past project contributors, of course.  If
>    it is too high, having such a list may help for (1) and (3)
>    above.

In addition to checking git-shortlog on the Git repo, perhaps it's also worth running a similar query against the public-inbox repo of this list? We could perhaps use a script to generate this list automatically every Git release (or some other cadence that we undergo regularly)?

Show 8 quoted lines

>  - How binding is it for a contributor to be on this list as an area
>    expert?  Will there be concrete "expected response time"?  It can
>    be different for each area expert, of course.  I'd expect better
>    from those who work on Git as a major part of their job and
>    contributes some part of their work product back to the upstream,
>    than from folks who do Git as a hobby.  Is each contributer
>    expected to volunteer to be on this list, with self declared
>    service level target?

Ideally there should be some teeth to the document/agreement (esp for service level targets), but I think practically the best we can do is positive reinforcement. So maybe a prominent "The Git Code Review Team" web page (somewhere on git-scm.com?) with profile photos and short biographies should be enough to motivate people to stay engaged and keep their spot.

I realize that such an idea is beyond the scope of a simple MAINTAINERS (or similar) file that's checked into the Git code repo, but I think it's worth stating as a thought experiment. The overall point I want to make is that we need to be extra-thankful to those who sign up to say "yes, I can review patches in areas X, Y, Z" and recognize (in a very official way) their generosity in contributing back to this project.

Show 7 quoted lines

>  - With many good reviewer candidates being employed in companies
>    and doing Git as part of their job, how would we handle folks
>    getting transferred out of the Git ecosystem?  Unlike in a
>    corporate environment, nominating successors who have no track
>    record in the community by the current area expert would not work
>    at all.  The successors themselves have to earn respect by
>    demonstrating their own competence, which would take time.

Unfortunately I don't think there's a good answer here. I agree that only those who have demonstrated a good track record should become a "successor".

OTOH, if we are fortunate enough to have multiple people sign up for a particular area, then maybe that can be a sub-team and finding a successor won't be such a big deal. It would only be a problem for those areas where there is only 1 person who signed up for it.