llvm dev - Feb 2020 - [cfe-dev] RFC: Switching from Bugzilla to Github Issues

Would it make sense to wait until 10.0.0 is released, in order to keep all
the blockers in one place?



On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <
llvm-dev at 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
> > <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.
> >>
> >> 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 <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> 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
> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> 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/llvm-dev/attachments/20200130/c0bff4c6/attachment.html>

I tend to support this – after 10.0.0 seems like a proper timeline.

And we already have some set of tags from bugzilla, so we could simply add them.

On Thu, Jan 30, 2020 at 8:49 PM David Major via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Would it make sense to wait until 10.0.0 is released, in order to keep all
the blockers in one place?
>
>
>
> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <llvm-dev at
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
>> > <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.
>> >>
>> >> 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 <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> 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
>> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>
>> >>
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200130/cfd33105/attachment-0001.html>

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 <llvm-dev at
lists.llvm.org <mailto:llvm-dev at 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
>     > <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.
>     >>
>     >> 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 <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 <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On 02/10/2020 07:40 PM, Tom Stellard wrote:
> 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.
> 
Hi,

10.0.0-rc4 was just released, and I think we are at the point in the release
cycle
where it is safe to begin the migration to GitHub issues.

I would like to propose doing the migration in one week (March 23).  This means
making the existing bugzilla read-only, and updating the documentation to tell
users
to file issues at GitHub.  We are still trying to figure out the best way to
import bugs
from bugzilla into GitHub, so this step will be done at a later date.

For the initial list of tags, I propose we generate the list based on the most
commonly
used categories in bugzilla.  This should be enough to get us started and we can
always
add more tags as we go.

I've also implemented a notification system using GitHub actions that will
make
it possible to subscribe to individual issue tags, so we would enable this on
Monday
as well.

What does everyone think?

Thanks,
Tom

> -Tom
> 
>>
>>
>> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at 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
>>     > <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.
>>     >>
>>     >> 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
<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 <mailto:llvm-dev at
lists.llvm.org>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>