[llvm-dev] Proposal for an alternative bugtracking workflow
Sam McCall via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 15 05:01:29 PST 2019
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
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
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...
More information about the llvm-dev