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

[James Y Knight via llvm-dev]

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.


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191024/7ee65da3/attachment.html>