<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 24, 2020 at 12:04 PM Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 04/24/2020 03:24 AM, Sam McCall wrote:<br>
> clangd's experience using github issues to track bugs (in a separate repo) has been very positive, and I'm glad you're pushing on this!<br>
> <br>
> Part of this has been that our issue tracker has been scoped to our subproject only, which is a scope that the tool works well for (on the user and developer side).<br>
> As such I don't think we should migrate clangd to a using the monorepo bugtracker. Email subscription to a label is better than nothing, but worse than a separate repo.<br>
> Removing the clangd label from the monorepo bugtracker seems like the simplest thing, though I'm happy to work on auto-moving bugs if that's better.<br>
> <br>
> (I'd suggest considering the same for other subprojects, though I know that's not a popular opinion here)<br>
<br>
I think it's important for everything in the monorepo to use the same bug tracker.<br>
<br>
There are advantages to having code in the monorepo (e.g. free<br>
updates for API changes, a more consistent build experience, etc.).<br>
But there are also costs, as you have pointed out, like having to use<br>
a less than ideal bug tracker.  It's really up to sub-projects<br>
to make the decision about whether these benefits are worth the costs.<br>
The flang developers have just gone through this process and have<br>
had to make some sacrifices to get the code in, but ultimately felt the<br>
sacrifices were worth it. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I think it hurts the ability of developers and users to collaborate effectively,<br>
if the infrastructure for the project is spread across too many different places.<br>
And good collaboration is key for a project of this size with some many tightly<br>
connected components.<br></blockquote><div><br></div><div>+1: seems like clangd here is trying a "in-between" approach in being halfway into a LLVM project. It was something that was strongly pushed back against multiple times during the discussions on Flang integration, it isn't clear to me why we'd get into a different approach with clangd. I am really in favor of keeping a cohesion in the project and not having a "graph of somehow disconnected projects". There might be sub-optimality sometimes, but we should address them for everyone instead of one-off improvements that may benefit one subproject on the short term but I suspect hurt the project on the long term.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Getting back to the proposal we are discussing.  Do you have any specific feedback<br>
for improvements that might help make it align better with the kind of experience<br>
the clangd users and developers are looking for?<br>
<br>
- Tom<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>