[cfe-dev] LLVM/Clang Maintainers Organigram??

[Chandler Carruth]

My 2 cents on this issue:

On Fri, Jan 9, 2015 at 12:50 PM, Mikael Persson <mikael.s.persson at gmail.com>
wrote:

> Thanks, that seems to be what I was looking for.
>
> It is, however, kind of coarse. Maybe you should consider updating it and
> expanding it to a more fine-grained listing. I also think that this list
> could be publicized a bit more, so that one can actually find it more
> easily through the LLVM/Clang web-site and via google searches.
>

I disagree, but perhaps not for the reason you might imagine. See below,
I'll try to address this along with several other poinst.


>
> It didn't occur to me, right away, to inspect revision histories for some
> files as a way to get the few relevant names for a specific part of
> llvm/clang.
>
<snip>

>
> Even though you could say "you should have thought about checking
> code_owners and/or revision histories", my humble feedback as an outsider
> is that I didn't think of that or know that, indicating that there might be
> a need for a more publicized / obvious way of getting to that information.
>

I completely agree. Both reaching out to code owners or crawling through
revision history should be a very rare occurrence in general, and is not
what we should (or do as you've noticed) publicize.


> Finally, isn't the concept of "code owners" (from LLVM's docs) a bit
> fuzzy? Not really maintainers, not really reviewers, not really
> responsibility-baring, not really vetted / elected / performance-reviewed,
> etc... I would suggest that this might be formalized a bit more, in terms
> of responsibilities and expectations.
>

This was raised when we added code owners. The goal of that effort was not
to create long-term maintainers where we previously had none, but to
delegate a specific responsibility: that of either providing or finding an
adequate code review for a specific patch which is failing to get reviewed.
Essentially, it is an escalation path when the normal processes fail to
work. I think that is how it best serves the community as well.


> Also, how would you detect that a part of llvm or clang is being
> under-maintained? Or that a particular maintainer is being over-whelmed by
> what he/she is responsible for? Except anecdotally or by complaints. For
> example, if a particular maintainer is consistently drowned in pending
> patch reviews, then that should and could be detected. There could also be
> more formalized dead-lines and stuff to make sure patches don't just drop
> off into the ether, or require constant bumping or re-submitting of them to
> pester the maintainers until they budge.
>

These issues are typically raised on the mailing list, usually by the
maintainer themselves (IE, a request for help with X), and get addressed.
It is case by case, and certainly could be structured or rigorous, but so
far that hasn't been necessary.


Ultimately I feel like the high-order bit answer to a lot of your questions
stems from needing to strengthen this comment up-thread:


> > you can just write questions to the mailing list and a person, who
> takes responsibility and/or has a good domain knowledge, might pick your
> question/patch and provide some help or advice.
>

This isn't just "might". The *canonical* way to contribute is to send to
the entire mailing list. Not to a person, not to a code owner, etc. If no
one on the list attends to a patch, it is the responsibility of the code
owner to pick up the slack or find others to pick up the slack. The purpose
of this is in fact to make the community more inclusive. You

Now, do we publicize this enough? I think for LLVM we do. I just tried, and
the top hit I see on various searches such as "llvm submitting a patch" are
all the developer policy[1], which is the canonical document for what to do
here. And it has a pretty straight forward process that should match the
above. It also has links to the code owners to allow for escalating when
things get busy and a patch gets lost.

We may not publicize it as much fro clang, but the top hit I get for "clang
submit a patch" is the clang hacking document[2] which does defer to the
LLVM developer policy. A bit round-about. We could probably do better to
document how to submit a patch to Clang. If you're up for improving our
documentation, contributions there would be wonderful. Newcomers often
write much better docs because they don't assume as much common knowledge.


All that said, I don't want to discourage work on more organized
information about who maintains what parts of LLVM. It would be really cool
to have, and right now it is essentially ad-hoc and based on folks piping
up on the list when appropriate. However, I've not seen a huge problem of
parts of Clang being without maintainers, just a problem of there being
very few maintainers for a very large project. Within LLVM we have more
problems of subsystems without maintainers, but those tend to either be
very rare and quickly fixed, or well documented and still corrected over
time. (For example, a backend for a target will periodically be without
sufficient attention, but we know who to ask to step up, and eventually it
is either corrected or the backend is removed without any real
disagreement.) So from my perspective this would be nice to have, but isn't
fixing a huge problem for the community. If you are finding it to be a
problem, that is of course important to understand and address.


-Chandler

[1]: http://llvm.org/docs/DeveloperPolicy.html
[2]: http://clang.llvm.org/hacking.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150109/e292be94/attachment.html>