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

[Sam McCall via llvm-dev]

On Sat, Apr 25, 2020, 3:43 AM Michael Kruse <llvm at meinersbur.de> wrote:

> Am Fr., 24. Apr. 2020 um 16:13 Uhr schrieb Sam McCall via cfe-dev
> <cfe-dev at lists.llvm.org>:
> > On Fri, Apr 24, 2020 at 9:03 PM Tom Stellard <tstellar at redhat.com>
> 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.
> >
> > (sorry, I should probably not tilt at this windmill. More on-topic stuff
> below, I promise!)
> > Right, and I think having a single-project view of the LLVM organization
> is a mistake: it's a graph of projects, some are highly connected and some
> are not.
> > The monorepo has a strong technical reason: the graph is connected and
> accepting a CI boundary anywhere is expensive in the absence of stable APIs.
> > But this is much less true for bug tracking systems: the cost to
> crossing boundaries is smaller.
> > For clangd, the benefit of sharing a tracker with clang AST+Sema is less
> than the cost of sharing a tracker with clang codegen, LLVM proper, LLD,
> flang, MLIR, ... (and the opposite is true for source control/CI).
> > Anyway, this is going to depend on what part(s) of the project graph you
> touch: people connected to many parts will want to make coordinating with
> hundreds of people incrementally, while people connected to few parts are
> far better served by communicating only with the people they need to
> (communication famously scales badly).
>
> I think there is another aspect important to mention. Users not
> familiar with the LLVM developers tooling will see an official GitHub
> project that allows submitting bugs.

I don't expect this to be a big problem, very few of our users really know
what LLVM is, or would think to search for an LLVM bug tracker instead of
the clangd one.
(This is one of the reasons that expecting them to use the LLVM bug tracker
is a problem)

But if it is, id expect templates and/or auto-migrating bugs to solve this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200425/abc0c5d2/attachment-0001.html>