On 01/31/2020 01:21 AM, James Henderson wrote: > My only concern is the ability to get auto-subscribed onto issues for > specific tools (i.e. the setup I currently have). If that can be resolved in > a satisfactory manner, then I'm all for this (although less than two weeks > seems like a rather ambitious time to switch over...). If it can't, then I'd > be opposed to switching at all. >
Would you be able to help me test some potential solutions for this? -Tom > On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev > <llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> wrote: > > On 01/30/2020 10:48 AM, Mehdi AMINI wrote: > > Hi, > > > > > > > > > > On Thu, Jan 30, 2020 at 10:21 AM Tom Stellard via cfe-dev > <cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto: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. > > > > > > Do we have a way for individuals to get individually automatically > subscribed on all the bugs created for a given tag? > > Mailing-lists seem fairly rigid in terms of granularity with respect to > tags. > > > > When I said cc lists, I really meant auto-subscribe lists, I didn't mean > that we would start sending issue emails to mailing lists. > > From what I can tell, there are a couple different ways to auto-subscribe > people using github actions. I think the most simple would be to use > the assignee field, but I think it's also possible by @ mentioning people > directly in a comment or @ mentioning teams. > > I was planning to experiment more with this over the next few days. > > -Tom > > > > > > > -- > > Mehdi > > > > > > > > > > > > > > What does everyone think about this? > > > > -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> <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>> <mailto: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> > <mailto: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> > <mailto: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
