<div dir="ltr"><div dir="ltr">+llvm-dev <br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 14, 2019 at 1:46 PM David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 14/01/2019 10:36, Ilya Biryukov via llvm-dev wrote:<br>
> To reiterate, our proposal was to create a repository for each of the <br>
> LLVM subprojects under the official LLVM GitHub account, e.g. <br>
> <a href="http://github.com/llvm/clangd" rel="noreferrer" target="_blank">github.com/llvm/clangd</a> <<a href="http://github.com/llvm/clangd" rel="noreferrer" target="_blank">http://github.com/llvm/clangd</a>>.<br>
> This repository would be run by the part of the community working on <br>
> that project and would host the issue tracker for the project. The <br>
> existing '<a href="http://github.com/llvm/llvm-project" rel="noreferrer" target="_blank">github.com/llvm/llvm-project</a> <br>
> <<a href="http://github.com/llvm/llvm-project" rel="noreferrer" target="_blank">http://github.com/llvm/llvm-project</a>>' repository will be used to solely <br>
> host the code, it will not have an issue tracker associated with it.<br>
> <br>
> Do you think this workflow would be a good fit for tracking bugs in LLVM?<br>
<br>
It's quite annoying to have a bug tracker on GitHub that isn't in the <br>
same place as the code.  GitHub lets you close bugs by putting things <br>
like 'Fixes #123' in the commit message.  If we add a bug tracker to <br>
llvm/llvm-project in the future ever, then messages like this in clangd <br>
commits will close the wrong bugs and we can't use this directly to <br>
close bugs.</blockquote><div>It's true and unfortunate that 'Fixes #123' comments don't work with this approach.</div><div>We can avoid closing random issues (which would be most annoying), by removing </div><div>an issue tracker from llvm-project repo that hosts the code, otherwise people will </div><div>constantly get confused anyway.</div><div>Point taken, certainly a bad thing that code and issues are in different (albeit) close</div><div>locations.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The big advantage of using GitHub's issue tracker is its integration <br>
with the rest of the workflow.  For example, if you send a pull request <br>
with 'Fixes #123' in the commit message, then this shows up <br>
automatically in the bug's stream with a message saying that the issue <br>
will be closed automatically if the pull request is merged.  I don't <br>
believe that this works across repos, even if you do manage the full <br>
invocation (llvm/clangd#123, I think, but I end up having to look it up <br>
every time, because you can't test it without pushing).  You can't send <br>
a pull request to the llvm repo that will close a clangd bug and have it <br>
show up in the issue feed.<br>
<br>
I've worked with a downstream pair of clang and llvm repos hosted on <br>
GitHub, with associated issue trackers.  People often filed bugs on the <br>
wrong component (e.g. an LLVM bug causes clang to crash, people filed a <br>
clang bug) and for other people (not just me!) to then close an </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
unrelated bug by putting 'Fixes #12' in their commit message and forget <br>
that it's clang bug 12, not llvm bug 12.<br></blockquote><div>Now that the bugs can be moved across different repos, one can at least move</div><div>the bugs into the proper component.</div><br class="gmail-Apple-interchange-newline"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This may be fine when we have only clangd using the GitHub issue <br>
tracker, but when we get a second or third project doing this then it <br>
quickly becomes a problem.<br>
<br>
It is very easy with the GitHub issue tracker to filter bugs by tag.  It <br>
might be a better idea to have a clangd tag and use the <br>
llvm/llvm-project's issue tracker.  This would need someone to go and <br>
correctly tag things (only project members are allowed to modify tags, <br>
because they're used for things like 'this person has signed a CLA'), <br>
but it would give a workflow that would scale to more components using <br>
the issue tracker and would allow better integration with the rest of <br>
the GitHub tooling.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
David<br></blockquote><div>Would be interested in other GitHub tooling things that break on multi-project setups,</div><div>I would expect things like CI bots (i.e. Travis and such) to expect both code</div><div>and issues being hosted at the same project, but have no hands-on experience there.</div><div>Do you have anything in mind that might also break (other than 'Fixes #123' comments discussed above)?</div><div><br></div><div>The major downside of tag-based workflow is the fact that one can't subscribe to notifications</div><div>only for specific tags. Having a single issue tracker for all of LLVM would mean, e.g. that there's no </div><div>way for clangd developers to subscribe only for clangd issues and getting notified on **all** LLVM issues</div><div>would make the bug triaging process much more complicated on our side (we expect the number of clangd</div><div>bugs to be significantly less than the number of bugs for all backend+clang+lld+...)</div><div><br></div><div>-- <br></div></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div></div>