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

James Henderson via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 16 08:40:42 PDT 2020


On Mon, 16 Mar 2020 at 15:08, Tom Stellard <tstellar at redhat.com> wrote:

> On 03/16/2020 08:00 AM, James Henderson wrote:
> >
> >
> > On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> >
> >     On 02/10/2020 07:40 PM, Tom Stellard wrote:
> >     > On 01/30/2020 12:47 PM, David Major wrote:
> >     >> Would it make sense to wait until 10.0.0 is released, in order to
> keep all the blockers in one place?
> >     >>
> >     >
> >     > Yes, I think this makes sense, let's postpone until then.
> >     >
> >
> >     Hi,
> >
> >     10.0.0-rc4 was just released, and I think we are at the point in the
> release cycle
> >     where it is safe to begin the migration to GitHub issues.
> >
> >     I would like to propose doing the migration in one week (March 23).
> This means
> >     making the existing bugzilla read-only, and updating the
> documentation to tell users
> >     to file issues at GitHub.
> >
> >
> > Don't forget to update the URL used in crash messages to point at the
> right location.
> >
> >
> >     We are still trying to figure out the best way to import bugs
> >     from bugzilla into GitHub, so this step will be done at a later date.
> >
> >
> > Making bugzilla read-only seems like a bad idea until all existing
> issues have been migrated. What if people need to update an existing bug
> once the migration to using Github issues has happened before importing has
> also happened?
> >
>
> This was a mistake on my part.  The plan is to disable creation of new
> bugs in bugzilla and not
> to make it read-only.  If you look at the original RFC, it says GitHub
> issues
> would be used for new issues, and existing issues will continue to be
> updated in bugzilla,
> and this is what I'm proposing.
>
> >
> >
> >     For the initial list of tags, I propose we generate the list based
> on the most commonly
> >     used categories in bugzilla.  This should be enough to get us
> started and we can always
> >     add more tags as we go.
> >
> >
> > I'd like this list to be fleshed out before migration is agreed. I'm
> concerned different people will have wildly different ideas of what
> "commonly used" might mean, which could in turn have an impact on the
> viability of this tag list.
> >
>
> Most commonly used here means categories with the most bugs.  So, this
> would be
> based on raw bug counts and not just someone's opinion.
>
> -Tom
>

That's what I thought might be the case, and where I take issue with it.
I've said this on several previous occasions - I think it makes sense for
tags/bugzilla components etc. to exist for each individual executable, as
well as the various libraries. Let's say I'm a user of a tool like
llvm-size and I find a bug. If there wasn't a tag for llvm-size, I wouldn't
know where to file it (and no, I don't think a catch-all "binutils" tag is
useful - not every developer will know what counts as a "binutils" tag). At
the time of writing there are exactly three bugs for llvm-size. That
presumably isn't going to meet any threshold imposed, so this tag wouldn't
be created, and I wouldn't know where to file my bug, so I probably would
either guess (and quite likely get it wrong), or not add a tag, which means
that developers who are focused on developing the binutils (and would
therefore have subscribed to this tag) won't see the issue. I might even
not file the bug at all.


> >
> >
> >     I've also implemented a notification system using GitHub actions
> that will make
> >     it possible to subscribe to individual issue tags, so we would
> enable this on Monday
> >     as well.
> >
> >     What does everyone think?
> >
> >     Thanks,
> >     Tom
> >
> >
> >     > -Tom
> >     >
> >     >>
> >     >>
> >     >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> <mailto:
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>> wrote:
> >     >>
> >     >>     On 01/30/2020 10:24 AM, Aaron Ballman wrote:
> >     >>     > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> >     >>     > <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>> wrote:
> >     >>     >>
> >     >>     >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> >     >>     >>> We held a round-table at the llvm dev conference about
> what other pieces of Github infrastructure we may want to use. This thread
> in particular is about switching to github issue tracking. Use of other
> parts of Github functionality was also discussed -- but that should be for
> other email threads.
> >     >>     >>>
> >     >>     >>> Most of the ideas here were from other people. I
> /believe/ this proposal represents the overall feeling of the folks at the
> round-table, in spirit if not in exact details, but nobody else has
> reviewed this text, so I can't make any specific such claim as to who the
> "we" represents, other than myself. Just assume all the good ideas here
> were from others, and all the bad parts I misremembered or invented.
> >     >>     >>>
> >     >>     >>>
> >     >>     >>
> >     >>     >> Hi,
> >     >>     >>
> >     >>     >> I want to restart this discussion.  There seemed to be
> support for this,
> >     >>     >> but we got held up trying to decide on the appropriate set
> of tags to
> >     >>     >> use to classify issues.
> >     >>     >>
> >     >>     >> I propose that we move forward with this proposal and
> disable creation of
> >     >>     >> new bugs in bugzilla on Feb 11, and require all new bugs
> be filed via GitHub
> >     >>     >> issues from that date forward.
> >     >>     >>
> >     >>     >> I think that for choosing the tags to use, we should just
> take requests
> >     >>     >> from the community over the next week and add whatever is
> asked for.  The main
> >     >>     >> purpose of adding tags is so we can setup cc lists for
> bugs, so I think this
> >     >>     >> is a good way to ensure that we have tags people care
> about.  We can always
> >     >>     >> add more tags later if necessary.
> >     >>     >>
> >     >>     >> What does everyone think about this?
> >     >>     >
> >     >>     > What did we decide to do with all the existing issues in
> Bugzilla?
> >     >>     >
> >     >>
> >     >>     This is undecided.  The first step of this  proposal only
> affects new issues.
> >     >>     Existing issues will remain in bugzilla and will be updated
> there too.  At
> >     >>     some point in the future bugzilla will become read-only
> and/or the issues will
> >     >>     be migrated somewhere else, but no decision has been made
> about how to do that yet.
> >     >>
> >     >>     -Tom
> >     >>
> >     >>     > ~Aaron
> >     >>     >
> >     >>     >>
> >     >>     >> -Tom
> >     >>     >>
> >     >>     >>
> >     >>     >>> Background
> >     >>     >>> ----
> >     >>     >>> Our bugzilla installation is...not great. It's been
> not-great for a long time now.
> >     >>     >>>
> >     >>     >>> Last year, I argued against switching to github issues. I
> was somewhat optimistic that it was possible to improve our bugzilla in
> some incremental ways...but we haven't. Additionally, the upstream bugzilla
> project was supposed to make a new release of bugzilla ("harmony"), based
> on bugzilla.mozilla.org <http://bugzilla.mozilla.org> <
> http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which
> is much nicer. I thought we would be able to upgrade to that. But there has
> been no such release, and not much apparent progress towards such. I can't
> say with any confidence that there will ever be. I no longer believe it
> really makes sense to continue using bugzilla.
> >     >>     >>>
> >     >>     >>> This year, we again discussed switching. This time,
> nobody really spoke up in opposition. So, this time, instead of debating
> /whether/ we should switch, we discussed /how/ we should switch. And came
> up with a plan to switch quickly.
> >     >>     >>>
> >     >>     >>> GitHub issues may not be perfect, but I see other
> similarly-large projects using it quite successfully (e.g. rust-lang/rust)
> -- so I believe it should be good for us, as well. Importantly, Github
> Issues is significantly less user-hostile than our bugzilla is, for new
> contributors and downstream developers who just want to tell us about bugs!
> >     >>     >>>
> >     >>     >>>
> >     >>     >>> Proposal
> >     >>     >>> ----
> >     >>     >>> We propose to enable Github issues for the llvm-project
> repository in approximately two weeks from now, and instruct everyone to
> start filing new issues there, rather than in bugzilla.
> >     >>     >>>
> >     >>     >>> Some things we'd like to get in place before turning on
> Github's Issue tracker:
> >     >>     >>> 1. Updated documentation.
> >     >>     >>> 2. An initial set of issue tags we'd like to use for
> triaging/categorizing issues.
> >     >>     >>> 3. Maybe setup an initial issue template. Or maybe
> multiple templates. Or maybe not.
> >     >>     >>>
> >     >>     >>> But more important are the things we do /not/ want to
> make prerequisites for turning on Github issues:
> >     >>     >>>
> >     >>     >>> We do /not/ yet plan to turn off Bugzilla, and do /not/
> plan to migrate the existing issues to GitHub as a prerequisite for
> switching. We will thus expect that people continue using bugzilla for
> commenting on the existing bugs -- for the moment.
> >     >>     >>>
> >     >>     >>> We do /not/ want to build supplementary notification
> systems to make github issues send additional emails that it is unable to
> send itself. We will only support what GitHub supports. That means:
> >     >>     >>> - You can subscribe to notification emails for activity
> in the entire llvm-project repository.
> >     >>     >>> - You can subscribe to notification emails on an
> individual issue.
> >     >>     >>> - Someone else can CC you on an individual issue to get
> your attention, and you will get notifications from that (unless you
> opt-out).
> >     >>     >>> - No emails will be sent to llvm-bugs at llvm.org <mailto:
> llvm-bugs at llvm.org> <mailto:llvm-bugs at llvm.org <mailto:llvm-bugs at llvm.org>>
> <mailto:llvm-bugs at llvm.org <mailto:llvm-bugs at llvm.org> <mailto:
> llvm-bugs at llvm.org <mailto:llvm-bugs at llvm.org>>> for github issues.
> >     >>     >>> - There is no builtin way for users to subscribe to
> emails for bugs that have a given label (for example, all "clang" issues,
> or all x86 issues).
> >     >>     >>>
> >     >>     >>> Further steps
> >     >>     >>> ----
> >     >>     >>> After we migrate, there's still things we want to do:
> >     >>     >>>
> >     >>     >>> 1. Discuss and setup new and better procedures around bug
> triage and prioritization.
> >     >>     >>>
> >     >>     >>> What we have been doing up until now has not been great
> in any case. Switching bug-trackers is a great opportunity to try to do
> something better. E.g., like what the rust project has done (
> https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage,
> https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
> >     >>     >>>
> >     >>     >>> 2. Bug migration
> >     >>     >>>
> >     >>     >>> /After/ the initial switchover, we do want to investigate
> two possibilities for migrating issues and turning off the bugzilla server.
> I expect which one is chosen will come down mostly to feasibility of
> implementation.
> >     >>     >>>
> >     >>     >>> Possibility 1: Migrate /all/ the existing bugs into a
> secondary "llvm-bugs-archive" github repository, and then turn off
> bugzilla. Github offers the ability to move bugs from one repository to
> another, and so we can use this to move bugs that are still relevant
> afterwards (potentially this could be done automatically upon any
> activity). Then, shut down bugzilla, and leave behind only a redirect
> script.
> >     >>     >>>
> >     >>     >>> Possibility 2: Create the ability to import an individual
> bug from Bugzilla into the llvm-project repository by pressing a "migrate
> this bug to github" button. Then, leave bugzilla running only as a static
> snapshot -- as static as possible while leaving the "migrate this bug to
> github" button operational.
> >     >>     >>>
> >     >>     >>> In both cases, we'd want to support a redirect script to
> take you from the old bug ids to the migrated bug page. In both cases, we
> would /preserve/ the entire archive of existing bugs, but would not import
> the entire set into the "llvm-project" github repository.
> >     >>     >>>
> >     >>     >>>
> >     >>     >>>
> >     >>     >>> _______________________________________________
> >     >>     >>> LLVM Developers mailing list
> >     >>     >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto: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 <mailto:cfe-dev at lists.llvm.org>
> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
> >     >>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >     >>     >
> >     >>
> >     >>     _______________________________________________
> >     >>     LLVM Developers mailing list
> >     >>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto: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 <mailto: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/20200316/eb24ad98/attachment-0001.html>


More information about the llvm-dev mailing list