LLVM/Clang Maintainers Organigram??

Hi LLVM/Clang devs,

Does LLVM / Clang have some sort of publicly-available organigram of its maintainers? Something like the Linux kernel maintainers tree (https://www.kernel.org/doc/linux/MAINTAINERS).

I find this to be a pretty big entry barrier for people trying to contribute or help with LLVM or Clang. It says all over the submission process description and requirements that patches have to be reviewed by maintainers, that they can be contacted for help and things along those lines. But if I’m working on some specific part of llvm/clang, how on Earth am I supposed to know who is the appropriate maintainer to contact or tag on patches or questions for that specific part / module of llvm/clang?

It leaves a kind of “private club” impression, where there’s a facade of openness to community contributions with an effective restriction to “insiders”. As an outsider trying to contribute some patch(es), I can say that the hurdles are too much (e.g., contributing patches to Boost is like a walk in the park in comparison to LLVM/Clang).

Mikael.

Take a look at either CODE_OWNERS.TXT or the revision history for the files you want to change. This is in the documentation somewhere, but if you have specific spots you think it should live and it doesn’t, please list them. I’d be happy to update the documentation. If you have specific concrete suggestions on how to reduce this impression, please list them.

Hi, Mikael.
You may find CODE_OWNERS.TXT file at the root directory of project.
Also, as I see, 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.

Mikael Persson <mikael.s.persson@gmail.com> writes:

Does LLVM / Clang have some sort of publicly-available organigram of its
maintainers? Something like the Linux kernel maintainers tree (https://
www.kernel.org/doc/linux/MAINTAINERS).

I find this to be a pretty big entry barrier for people trying to contribute
or help with LLVM or Clang. It says all over the submission process
description and requirements that patches have to be reviewed by maintainers,
that they can be contacted for help and things along those lines. But if I'm
working on some specific part of llvm/clang, how on Earth am I supposed to
know who is the appropriate maintainer to contact or tag on patches or
questions for that specific part / module of llvm/clang?

It leaves a kind of "private club" impression, where there's a facade of
openness to community contributions with an effective restriction to
"insiders". As an outsider trying to contribute some patch(es), I can say that
the hurdles are too much (e.g., contributing patches to Boost is like a walk
in the park in comparison to LLVM/Clang).

Are the CODE_OWNERS files what you're looking for?

http://llvm.org/viewvc/llvm-project/llvm/trunk/CODE_OWNERS.TXT?view=markup
http://llvm.org/viewvc/llvm-project/cfe/trunk/CODE_OWNERS.TXT?view=markup

Look for CODE_OWNERS.TXT in the various repositories.

Joerg

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.

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. It seems that I had already tagged the right person for my patch (Sema / template instantiations, which seems to be Richard Smith’s responsibility (?) as I had guessed from his name coming up often on those related topics on the mailing list).

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. Simply mirroring the code-owners lists on the public webpage (and linking to it from submission instructions) would be great (on second examination, it seems that LLVM’s webpage link to it, but not the Clang “getting involved” instructions).

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

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.

That’s a very hit-and-miss process. Lots of stuff just drops off into the ether. Even the phabricator system is very hit-and-miss, from what I’m seeing.

If you have specific concrete suggestions on how to reduce this impression, please list them.

I don’t really have too many concrete suggestions. I’m really just providing my feedback or impressions as an uninitiated contributor. In coder-speak, just treat this as a “bug report” that I’m giving about this issue, and I don’t really have a patch for it, but I’ll think about it, and I hope you guys will too.

Cheers,
Mikael.

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.

The first hit on google for "llvm code owners" and "clang code owners" is
http://llvm.org/docs/DeveloperPolicy.html#code-owners
I'm not sure what else you want us to do.

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. It seems that I had already tagged the right person for my
patch (Sema / template instantiations, which seems to be Richard Smith's
responsibility (?) as I had guessed from his name coming up often on those
related topics on the mailing list).

Indeed. He's pretty busy though.

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.
Simply mirroring the code-owners lists on the public webpage (and linking
to it from submission instructions) would be great (on second examination,
it seems that LLVM's webpage link to it, but not the Clang "getting
involved" instructions).

I'm not aware of any page claiming to be "how to contribute patches" that
doesn't end up linking you back to:
http://llvm.org/docs/DeveloperPolicy.html
Also, this excellent presentation is among the first couple google results
for most searches relating to contributing to LLVM or Clang:
http://llvm.org/devmtg/2014-02/slides/ledru-how-to-contribute-to-llvm.pdf

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

We do know the answer to all these questions. We just don't have a
formalized system of keeping track of it. Having a formalized system has a
cognitive overhead that I don't think is worth it for the community.

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.

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

That's a very hit-and-miss process. Lots of stuff just drops off into the
ether. Even the phabricator system is very hit-and-miss, from what I'm
seeing.

I found that starting out with really small and obvious patches helped me
understand the community practices; once you get the groove it's it really
isn't that bad.

-- Sean Silva

My 2 cents on this issue:

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

Cool. I’m glad that my concerns have been heard. That’s all I really wanted.

Thanks,

Do let us know if you see a way to improve the documentation or make it
easier to navigate here. That is always good.