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
