[lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues
James Henderson via lldb-dev
lldb-dev at lists.llvm.org
Fri Jan 31 01:21:15 PST 2020
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.
On Thu, 30 Jan 2020 at 19:07, Tom Stellard via llvm-dev <
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>> 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>'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>>
> 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>
> > > 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>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-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/lldb-dev/attachments/20200131/5fb4e145/attachment.html>
More information about the lldb-dev
mailing list