On 4/25/20 10:02 PM, Mehdi AMINI via cfe-dev wrote:
On Fri, Apr 24, 2020 at 12:04 PM Tom Stellard via llvm-dev
<llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> wrote:
On 04/24/2020 03:24 AM, Sam McCall wrote:
> 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!
>
> 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).
> 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.
> 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.
>
> (I'd suggest considering the same for other subprojects, though
I know that's not a popular opinion here)
I think it's important for everything in the monorepo to use the
same bug tracker.
There are advantages to having code in the monorepo (e.g. free
updates for API changes, a more consistent build experience, etc.).
But there are also costs, as you have pointed out, like having to use
a less than ideal bug tracker. It's really up to sub-projects
to make the decision about whether these benefits are worth the costs.
The flang developers have just gone through this process and have
had to make some sacrifices to get the code in, but ultimately
felt the
sacrifices were worth it.
I think it hurts the ability of developers and users to
collaborate effectively,
if the infrastructure for the project is spread across too many
different places.
And good collaboration is key for a project of this size with some
many tightly
connected components.
+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.
+1. Agreed w/Mehdi.
--
Mehdi
Getting back to the proposal we are discussing. Do you have any
specific feedback
for improvements that might help make it align better with the
kind of experience
the clangd users and developers are looking for?
- Tom
_______________________________________________
LLVM Developers mailing list
llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
cfe-dev mailing list
cfe-...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
