On 01/30/2020 12:47 PM, David Major wrote:
> Would it make sense to wait until 10.0.0 is released, in order to keep all
> the blockers in one place?
>
Yes, I think this makes sense, let's postpone until then.
-Tom
>
>
> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev
> mailto: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
> > 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.
> >>
> >> 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
> '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
