Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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.
>
> - 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?
>
> - 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.
>
> There may be many others.
So here are some more from the top of my head.
- Corollary to "nominating successors from the group at your
company may not work well", it may be hard to self-nominate
yourself as an area expert if you are not confident that others
consider you to be one.
- How authoritative should these "maintainers" be? Do they have
the final say to even override a concensus in a discussion if
needed, when clueless discussion participants are drawing a
conclusion that would hurt the codebase in the longer term?
- For whom do we partition the areas? "For revision walking using
connectivity bitmaps, experts are ..." sounds (at least to me)
like a plausible and reasonable way to define an expertise area,
but the description of the area may be understood only by those
who are reasonably familiar with the way how "git log" internally
works, for example. Is it OK to assume that the reader has some
basic understanding of how the system works in order to use the
maintainer list effectively?
- The above worry may be reduced if we partition the area primarily
along the file boundaries. If a set of functions that are not
logically related to feature X but has to be in the same
compilation unit for some reason live in the file whose primary
purpose is to house implementation of the feature X, it may give
us an interesting project to figure out how to separate them out
and give them "correct" place, and the end result, even though it
is a side effect, would be a more modular and readable code.
- If we adopt the file format from the kernel project, can we
leverage their tooling as well to query the maintainers file? I
thought they have a tool that reads your patch into and figures
out what area is being touched to spit out a good set of Cc
candidates?
- Can contrib/contacts/git-contacts be taught about this new source
of information, and if so how?
- Once we start breaking down the system into expertise areas, are
there areas without any existng experts already? If you send
patches to the list right now in the following areas, I do not
think you'll find capable reviewers whose acks weigh well enough
[*]: gitk, git-gui, contrib/completion, git-p4, gitweb, git-svn.
* Please raise a hand and say "No, you know I am very familiar
with that area; you just simply forgot about me because we
have not seen any patches in the area recently".
- When there are no active area experts, what would the default
action be? We would risk degrading the quality of such
"neglected" part of the system if we adopt "anything gets
accepted blindly" approach, so I would really want to avoid it.
- When an area with incumbent experts sees interest from some
developers, it is the best for these new people to demonstrate
their own competence and earn community's trust to eventually
become the area experts themselves, but that may not be so easy
in practice due to chicken-and-egg problem.
