<div dir="ltr"><div class="gmail_extra">My 2 cents on this issue:</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 9, 2015 at 12:50 PM, Mikael Persson <span dir="ltr"><<a href="mailto:mikael.s.persson@gmail.com" target="_blank">mikael.s.persson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thanks, that seems to be what I was looking for.<div><br></div><div>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.</div></div></blockquote><div><br></div><div>I disagree, but perhaps not for the reason you might imagine. See below, I'll try to address this along with several other poinst.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><snip></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> 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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div>Ultimately I feel like the high-order bit answer to a lot of your questions stems from needing to strengthen this comment up-thread:</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div>> <span style="font-size:13px;color:rgb(0,0,0);font-family:Helvetica,Arial">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.</span><br></div></span></div></blockquote></div><br>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</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1]: <a href="http://llvm.org/docs/DeveloperPolicy.html">http://llvm.org/docs/DeveloperPolicy.html</a></div><div class="gmail_extra">[2]: <a href="http://clang.llvm.org/hacking.html">http://clang.llvm.org/hacking.html</a></div></div>