On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
<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?
~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 <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>
> > 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
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> _______________________________________________
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
