I tend to support this – after 10.0.0 seems like a proper timeline. And we already have some set of tags from bugzilla, so we could simply add them.
On Thu, Jan 30, 2020 at 8:49 PM David Major via llvm-dev <llvm-...@lists.llvm.org> wrote: > > Would it make sense to wait until 10.0.0 is released, in order to keep all > the blockers in one place? > > > > On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev > <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> 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>'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> 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 >> >>> 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 >> > >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev