Re: [PATCH] RFC: add MAINTAINERS file

[Taylor Blau <me@ttaylorr.com>]

On Sat, Mar 23, 2024 at 12:19:15PM -0700, Junio C Hamano wrote:
>  - 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.

I might be biased, but I think that we are not quite there, yet.
Subjectively, I find myself working in areas where I mostly know who to
CC based on what parts of the tree that I'm touching. But in the cases
where I do not, the shortlog --since=2.years.ago is usually pretty
small.

The output below lists number of individuals in the right-hand column,
and the number of files with that many individuals having touched it in
the last two years in the left-hand column:

    for f in $(git ls-files **/*.{c,h})
    do
      git shortlog -s --since-as-filter=2.years.ago -- $f | wc -l \
        || return 1
    done |
    sort -n | uniq -c | sort -rnk1
        192 1
        160 0
        112 2
         94 3
         80 4
         68 5
         40 6
         30 9
         27 8
         25 7
         19 11
         12 10
         11 12
          5 17
          5 14
          3 13
          2 18
          2 16
          1 22
          1 20
          1 19
          1 15

So a vast majority of *.ch files have fewer than 10 individuals working
on it in the past two years. By my count, there are 891 total source
files matching **/*.{c,h}, 828 of which have fewer than 10 people
working on it.

IOW, ~92.3% of the project is touched by no more than 9 people in the
last two years.

That kind of scale doesn't strike me as something that needs something
like a MAINTAINERS file to help make sense of it. It's possible that
some of the files that see more contributors might need some sort of
aide, but there are so few of them I have a hard time imagining it.

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

I share your concern here, too.

Another thought that comes to mind is the difference between
"maintainer" and "reviewer". For a file with, say, 4 committers in the
past two years, I imagine that as the maintainer that you'd give about
equal weight to any of their reviews (with obvious exceptions, like if
someone had showed up in the shortlog over a much longer period, or had
significantly more or substantial patches in a given area).

Those kinds of things are hard to quantify exactly, and perhaps that is
the point of a MAINTAINERS file. But I think quantifying those things
matters a lot more when you have dozens or more individuals contributing
to files across the tree, and the numbers above show that (at least for
a large majority of the project) we're simply not there yet.

Thanks,
Taylor