On 03/16/2020 07:53 AM, Aaron Ballman wrote: > On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev > <cfe-...@lists.llvm.org> wrote: >> >> On 02/10/2020 07:40 PM, Tom Stellard wrote: >>> 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. >>> >> >> Hi, >> >> 10.0.0-rc4 was just released, and I think we are at the point in the release >> cycle >> where it is safe to begin the migration to GitHub issues. >> >> I would like to propose doing the migration in one week (March 23). This >> means >> making the existing bugzilla read-only, and updating the documentation to >> tell users >> to file issues at GitHub. We are still trying to figure out the best way to >> import bugs >> from bugzilla into GitHub, so this step will be done at a later date. >> >> For the initial list of tags, I propose we generate the list based on the >> most commonly >> used categories in bugzilla. This should be enough to get us started and we >> can always >> add more tags as we go. >> >> I've also implemented a notification system using GitHub actions that will >> make >> it possible to subscribe to individual issue tags, so we would enable this >> on Monday >> as well. >> >> What does everyone think? > > I am uncomfortable switching to GitHub issues unless the initial > result is that we have ONE set of bugs to track (I do not want to have > to search and maintain separate bug lists). Moving bugs from Bugzilla > at an unspecified future time is a deal-breaker for me, so -1.
Is there anything we could do to make having active issues in both trackers easier to deal with? -Tom > > ~Aaron > >> >> Thanks, >> Tom >> >> >>> -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 >>>> >>> >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
