[llvm-dev] Proposal for an alternative bugtracking workflow

[Ilya Biryukov via llvm-dev]

+llvm-dev

On Mon, Jan 14, 2019 at 1:46 PM David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:

> On 14/01/2019 10:36, Ilya Biryukov via llvm-dev wrote:
> > To reiterate, our proposal was to create a repository for each of the
> > LLVM subprojects under the official LLVM GitHub account, e.g.
> > github.com/llvm/clangd <http://github.com/llvm/clangd>.
> > 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
> > existing 'github.com/llvm/llvm-project
> > <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
> close bugs.

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


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


> David
>
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+...)

-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/5e0d59ba/attachment.html>