I'm happy to test things out, as long as it's not too much of a time sink (I have a lot on my plate at the moment, so something that takes more than the odd few minutes here and there may not be feasible).
On Sat, 1 Feb 2020 at 02:10, Fangrui Song <mask...@google.com> wrote: > On 2020-01-31, Tom Stellard via llvm-dev wrote: > >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? > > My feeling is similar to James'. > > +1 if auto subscription is available (similar to Herald rules). > -1 if it isn't. > > And I guess contributors may need to change the notification setting from > "Watching" to "Not watching", > to avoid issue spam. > > > Tom, I'd like to be a tester. > > > > >> 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 > >> > > > >_______________________________________________ > >LLVM Developers mailing list > >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
