[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Philip Reames via llvm-dev]

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-dev at lists.llvm.org <mailto:llvm-dev at 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-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200427/5109ddb8/attachment.html>