On 01/30/2020 12:47 PM, David Major wrote: > Would it make sense to wait until 10.0.0 is released, in order to keep all > the blockers in one place? >
Yes, I think this makes sense, let's postpone until then. -Tom > > > On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev > <llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> wrote: > > On 01/30/2020 10:24 AM, Aaron Ballman wrote: > > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev > > <cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> wrote: > >> > >> On 10/24/2019 07: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. > >>> > >>> > >> > >> Hi, > >> > >> I want to restart this discussion. There seemed to be support for > this, > >> but we got held up trying to decide on the appropriate set of tags to > >> use to classify issues. > >> > >> I propose that we move forward with this proposal and disable creation > of > >> new bugs in bugzilla on Feb 11, and require all new bugs be filed via > GitHub > >> issues from that date forward. > >> > >> I think that for choosing the tags to use, we should just take requests > >> from the community over the next week and add whatever is asked for. > The main > >> purpose of adding tags is so we can setup cc lists for bugs, so I > think this > >> is a good way to ensure that we have tags people care about. We can > always > >> add more tags later if necessary. > >> > >> What does everyone think about this? > > > > What did we decide to do with all the existing issues in Bugzilla? > > > > This is undecided. The first step of this proposal only affects new > issues. > Existing issues will remain in bugzilla and will be updated there too. At > some point in the future bugzilla will become read-only and/or the issues > will > be migrated somewhere else, but no decision has been made about how to do > that yet. > > -Tom > > > ~Aaron > > > >> > >> -Tom > >> > >> > >>> 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> > <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. > >>> > >>> 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-b...@llvm.org > <mailto:llvm-b...@llvm.org> <mailto:llvm-b...@llvm.org > <mailto:llvm-b...@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-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>> > >> > >> _______________________________________________ > >> cfe-dev mailing list > >> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
