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

Fri Oct 25 11:47:18 PDT 2019

Generally supportive here, but I see a couple of small concerns.

On 10/24/19 7: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.
>
>
> 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>'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.
I think two weeks is simply too quick.  Our community is huge, there's 
inherently a delay with information dissemination and we want objectors 
to have a chance to respond.  4-8 weeks would be a much more realistic 
time frame.
>
> 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> 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).

The last two items are *very* unfortunate.  A quick skim through the API 
documentation (https://developer.github.com/v3/issues/) would seem to 
indicate implementing these fairly straight forward.  I think it might 
be worth implementing our own custom scripts here.

I'm legitimately torn as to whether this should be considered a 
blocker.  I don't actually use either method, so my personal vote is no, 
but I believe others do.  Breaking existing workflows when relatively 
little effort is required not to seems less than idea.

>
> 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/20191025/e010e789/attachment.html>