<div dir="ltr"><div dir="ltr">On Tue, Jan 15, 2019 at 1:45 PM Ilya Biryukov via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">The major downside of tag-based workflow is the fact that one can't subscribe to notifications<br></div><div class="gmail_quote"><div>only for specific tags. Having a single issue tracker for all of LLVM would mean, e.g. that there's no </div><div>way for clangd developers to subscribe only for clangd issues and getting notified on **all** LLVM issues</div><div>would make the bug triaging process much more complicated on our side (we expect the number of clangd</div><div>bugs to be significantly less than the number of bugs for all backend+clang+lld+...)</div></div></div></blockquote><div><br></div><div>There's another downside that's IMO bigger (and not addressed by an e.g. API-based solution, or even Github offering this feature).</div><div><br></div><div>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.</div><div>Instead of X home -> browse bugs -> file bug, the path becomes LLVM home -> browse bugs -> browse X bugs -> file bug -> file X bug.</div><div>It takes longer, there are more chances to get lost and confused.</div><div><br></div><div>(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)</div></div></div>