llvm dev - Jan 2019 - Proposal for an alternative bugtracking workflow

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

On Tue, Jan 15, 2019 at 4:45 AM Ilya Biryukov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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+...)
>
Has anyone reached out to GitHub about potentially enabling this?

Or is it possible to implement via their API?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/58f0d44a/attachment.html>

On Tue, Jan 15, 2019 at 1:45 PM Ilya Biryukov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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+...)
>
There's another downside that's IMO bigger (and not addressed by an e.g.
API-based solution, or even Github offering this feature).

When multiple projects share a repository, partitioned by tags, then the
"file bug", "browse bugs", "search bugs" actions
are too far apart in the
UI.
Instead of X home -> browse bugs -> file bug, the path becomes LLVM home
->
browse bugs -> browse X bugs -> file bug -> file X bug.
It takes longer, there are more chances to get lost and confused.

(This is assumes there's little overlap between projects in terms of bugs,
which may not be true for e.g. llvm-backend <-> clang, certainly is true
for clangd, other projects are probably debatable)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/08fb2139/attachment-0001.html>

On Tue, Jan 15, 2019 at 1:47 PM Chandler Carruth <chandlerc at gmail.com>
wrote:
> Has anyone reached out to GitHub about potentially enabling this?
>
For the lack of a better place, filed a ticker against GitHub support. Will
update the thread when they come back to me.

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