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