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

Thu Oct 24 20:01:13 PDT 2019

Yes, that should be possible to do that without also disabling comments on
existing issues.

On Thu, Oct 24, 2019 at 7:59 PM David Blaikie <dblaikie at gmail.com> wrote:

> Any chance of setting bugzilla to make it not possible to file new issues
> there?
>
> 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.
>>
>>
>> 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.
>>
>> _______________________________________________
>> 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/20191024/86e2f462/attachment.html>