[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues
James Henderson via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 3 03:03:14 PST 2020
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 <maskray at 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-dev at lists.llvm.org <mailto:llvm-dev at 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-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> <mailto:
> cfe-dev at lists.llvm.org <mailto:cfe-dev at 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-bugs at llvm.org <mailto:
> llvm-bugs at llvm.org> <mailto:llvm-bugs at llvm.org <mailto:llvm-bugs at llvm.org>>
> <mailto:llvm-bugs at llvm.org <mailto:llvm-bugs at llvm.org> <mailto:
> llvm-bugs at llvm.org <mailto:llvm-bugs at 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-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> >> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >> > >
> >> >
> >> > _______________________________________________
> >> > cfe-dev mailing list
> >> > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >> >
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >
> >_______________________________________________
> >LLVM Developers mailing list
> >llvm-dev at lists.llvm.org
> >https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/01fbd059/attachment.html>
More information about the llvm-dev
mailing list