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

Fri Oct 25 01:19:11 PDT 2019

On Thu, Oct 24, 2019 at 7:55 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>

Thanks for writing the proposal!
This is reflecting quite well the overall conclusion of the round-table on
this topic I think.

>
>
> 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'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 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.
>

Are you excluding his as a prerequisite because we don't have confidence
this can be achieved very quickly?

-- 
Mehdi

>
> 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
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191025/db4f3a9c/attachment.html>