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

Mikael Persson mikael.s.persson at gmail.com
Fri Jan 9 12:50:54 PST 2015


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150109/cc528eba/attachment.html>


More information about the cfe-dev mailing list