<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I strongly support this. I quite prefer GitHub issue to our current bugzilla setup.<div class=""><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 24, 2019, at 7:54 PM, James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Most of the ideas here were from other people. I <i class="">believe</i> 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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-size:large" class="">Background</span><br class=""></div>---- <div class=""><div class="">Our bugzilla installation is...not great. It's been not-great for a long time now.</div><div class=""><br class=""></div><div class="">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 <a href="http://bugzilla.mozilla.org/" class="">bugzilla.mozilla.org</a>'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.</div><div class=""><div class=""><br class=""></div><div class="">This year, we again discussed switching. This time, nobody really spoke up in opposition. So, this time, instead of debating <i class="">whether</i> we should switch, we discussed <i class="">how</i> we should switch. And came up with a plan to switch quickly.</div><div class=""><div class=""></div></div><div class=""><br class=""></div><div class="">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!</div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""></div></div><div class=""><font size="4" class="">Proposal</font></div><div class=""><font face="arial, sans-serif" class="">----</font></div><div class="">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.</div><div class=""><br class=""></div><div class=""><div class="">Some things we'd like to get in place before turning on Github's Issue tracker:</div><div class="">1. Updated documentation.</div><div class="">2. An initial set of issue tags we'd like to use for triaging/categorizing issues.</div><div class="">3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not.</div><div class=""></div></div><div class=""><br class=""></div><div class="">But more important are the things we do <i class="">not</i> want to make prerequisites for turning on Github issues:</div><div class=""><br class=""></div><div class="">We do <i class="">not</i> yet plan to turn off Bugzilla, and do <i class="">not</i> 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.</div><div class=""></div><div class=""><br class=""></div><div class="">We do <i class="">not</i> 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:</div><div class="">- You can subscribe to notification emails for activity in the entire llvm-project repository.</div><div class="">- You can subscribe to notification emails on an individual issue.</div><div class="">- Someone else can CC you on an individual issue to get your attention, and you will get notifications from that (unless you opt-out).</div><div class="">- No emails will be sent to <a href="mailto:llvm-bugs@llvm.org" class="">llvm-bugs@llvm.org</a> for github issues.</div><div class="">- 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).</div><div class=""><br class=""></div><div class=""><font size="4" class="">Further steps</font></div><div class="">----</div><div class=""></div><div class="">After we migrate, there's still things we want to do:</div><div class=""><br class=""></div><div class="">1. Discuss and setup new and better procedures around bug triage and prioritization.</div><div class=""><br class=""></div><div class="">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 (<a href="https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage" class="">https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage</a>, <a href="https://forge.rust-lang.org/release/triage-procedure.html#issue-triage" class="">https://forge.rust-lang.org/release/triage-procedure.html#issue-triage</a>).</div><div class=""><br class=""></div><div class="">2. Bug migration</div><div class=""><br class=""></div><div class=""></div><div class=""><i class="">After</i> 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.</div><div class=""><br class=""></div><div class="">Possibility 1: Migrate <i class="">all</i> 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.</div><div class=""><br class=""></div><div class=""><div class="">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.<br class=""></div><div class=""><br class=""></div><div class=""></div></div><div class="">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 <i class="">preserve</i> the entire archive of existing bugs, but would not import the entire set into the "llvm-project" github repository. </div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div class=""></div></div></div></div></div></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>