[llvm-dev] Proposal for an alternative bugtracking workflow

[Sam McCall via llvm-dev]

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>