llvm dev - Apr 2020 - RFC: Switching from Bugzilla to Github Issues [UPDATED]

Hi,

I wanted to continue discussing the plan to migrate from Bugzilla to Github.
It was suggested that I start a new thread and give a summary of the proposal
and what has changed since it was originally proposed in October.

== Here is the original proposal:

http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html

== What has changed:

* You will be able to subscribe to notifications for a specific issue
  labels.  We have a proof of concept notification system using github actions
  that will be used for this.

* Emails will be sent to llvm-bugs when issues are opened or closed.

* We have the initial list of labels:
https://github.com/llvm/llvm-project/labels

== Remaining issue:

* There is one remaining issue that I don't feel we have consensus on,
and that is what to do with bugs in the existing bugzilla.  Here are some
options
that we have discussed:

1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla that are
still active will be updated there until they are closed.  This means that over
time the number of active bugs in bugzilla will slowly decrease as bugs are
closed
out.  Then at some point in the future, all of the bugs from bugzilla will be
archived
into their own GitHub repository that is separate from the llvm-project repo.

2. Same as 1, but also create a migration script that would allow anyone to
manually migrate an active bug from bugzilla to a GitHub issue in the
llvm-project
repo.  The intention with this script is that it would be used to migrate
high-traffic
or important bugs from bugzilla to GitHub to help increase the visibility of the
bug.
This would not be used for mass migration of all the bugs.

3. Do a mass bug migration from bugzilla to GitHub and enable GitHub issues at
the same time.
Closed or inactive bugs would be archived into their own GitHub repository, and
active bugs
would be migrated to the llvm-project repo.


The key difference between proposal 1,2 and 3, is when bugs will be archived
from bugzilla
to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that we can
migrate
to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs
during the
transition (proposal 3) will delay the transition for a while (likely several
months)
while we evaluate the various solutions for moving bugs from bugzilla to GitHub.


The original proposal was to do 1 or 2, however there were some concerns raised
on the list
that having 2 different places to search for bugs for some period of time would
be very inconvenient.  So, I would like to restart this discussion and hopefully
we can
come to some kind of conclusion about the best way forward.

Thanks,
Tom

On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I wanted to continue discussing the plan to migrate from Bugzilla to
> Github.
> It was suggested that I start a new thread and give a summary of the
> proposal
> and what has changed since it was originally proposed in October.
>
> == Here is the original proposal:
>
> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
>
> == What has changed:
>
> * You will be able to subscribe to notifications for a specific issue
>   labels.  We have a proof of concept notification system using github
> actions
>   that will be used for this.
>
> * Emails will be sent to llvm-bugs when issues are opened or closed.
>
> * We have the initial list of labels:
> https://github.com/llvm/llvm-project/labels
>
> == Remaining issue:
>
> * There is one remaining issue that I don't feel we have consensus on,
> and that is what to do with bugs in the existing bugzilla.  Here are some
> options
> that we have discussed:
>
> 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla that
> are
> still active will be updated there until they are closed.  This means that
> over
> time the number of active bugs in bugzilla will slowly decrease as bugs
> are closed
> out.  Then at some point in the future, all of the bugs from bugzilla will
> be archived
> into their own GitHub repository that is separate from the llvm-project
> repo.
>
> 2. Same as 1, but also create a migration script that would allow anyone to
> manually migrate an active bug from bugzilla to a GitHub issue in the
> llvm-project
> repo.  The intention with this script is that it would be used to migrate
> high-traffic
> or important bugs from bugzilla to GitHub to help increase the visibility
> of the bug.
> This would not be used for mass migration of all the bugs.
>
> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
> issues at the same time.
> Closed or inactive bugs would be archived into their own GitHub
> repository, and active bugs
> would be migrated to the llvm-project repo.
>
Can we preserve the existing bug numbers if we migrate this way? There are
lots of references to "PRxxxxx" in checked in LLVM artifacts and
elsewhere
in the world, as well as links to llvm.org/PRxxxxx, and if we can preserve
all the issue numbers this would ease the transition pain substantially.

> The key difference between proposal 1,2 and 3, is when bugs will be
> archived from bugzilla
> to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that
> we can migrate
> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs
> during the
> transition (proposal 3) will delay the transition for a while (likely
> several months)
> while we evaluate the various solutions for moving bugs from bugzilla to
> GitHub.
>
>
> The original proposal was to do 1 or 2, however there were some concerns
> raised on the list
> that having 2 different places to search for bugs for some period of time
> would
> be very inconvenient.  So, I would like to restart this discussion and
> hopefully we can
> come to some kind of conclusion about the best way forward.
>
> Thanks,
> Tom
>
> _______________________________________________
> 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/20200420/21020d1e/attachment.html>

On 04/20/2020 12:49 PM, Richard Smith wrote:
> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>     Hi,
> 
>     I wanted to continue discussing the plan to migrate from Bugzilla to
Github.
>     It was suggested that I start a new thread and give a summary of the
proposal
>     and what has changed since it was originally proposed in October.
> 
>     == Here is the original proposal:
> 
>     http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
> 
>     == What has changed:
> 
>     * You will be able to subscribe to notifications for a specific issue
>       labels.  We have a proof of concept notification system using github
actions
>       that will be used for this.
> 
>     * Emails will be sent to llvm-bugs when issues are opened or closed.
> 
>     * We have the initial list of labels:
https://github.com/llvm/llvm-project/labels
> 
>     == Remaining issue:
> 
>     * There is one remaining issue that I don't feel we have consensus
on,
>     and that is what to do with bugs in the existing bugzilla.  Here are
some options
>     that we have discussed:
> 
>     1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla
that are
>     still active will be updated there until they are closed.  This means
that over
>     time the number of active bugs in bugzilla will slowly decrease as bugs
are closed
>     out.  Then at some point in the future, all of the bugs from bugzilla
will be archived
>     into their own GitHub repository that is separate from the llvm-project
repo.
> 
>     2. Same as 1, but also create a migration script that would allow
anyone to
>     manually migrate an active bug from bugzilla to a GitHub issue in the
llvm-project
>     repo.  The intention with this script is that it would be used to
migrate high-traffic
>     or important bugs from bugzilla to GitHub to help increase the
visibility of the bug.
>     This would not be used for mass migration of all the bugs.
> 
>     3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
issues at the same time.
>     Closed or inactive bugs would be archived into their own GitHub
repository, and active bugs
>     would be migrated to the llvm-project repo.
> 
> 
> Can we preserve the existing bug numbers if we migrate this way? There are
lots of references to "PRxxxxx" in checked in LLVM artifacts and
elsewhere in the world, as well as links to llvm.org/PRxxxxx
<http://llvm.org/PRxxxxx>, and if we can preserve all the issue numbers
this would ease the transition pain substantially.
>  
For all 3 proposals we want to be able to preserver the llvm.org/PRxxxx links so
that
they continue to provide useful information.  Eventually once bugzilla is shut
down,
those links would point to an issue somewhere in GitHub.

We don't have a solution for this today and this is one of the reasons why
proposal
3 will take so long to implement, because we need to solve this problem before
we start any
kind of transition.

This is also the reason why proposals 1 and 2 were originally favored, because
they allow us
to transition to GitHub issues for new bugs sooner, while still maintaining the
PRxxxx
links in bugzilla.  This gives us time to work out a good long-term solution to
maintaining
the links without further delaying the transition to GitHub issues.

-Tom


> 
>     The key difference between proposal 1,2 and 3, is when bugs will be
archived from bugzilla
>     to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means
that we can migrate
>     to GitHub issues sooner (within 1-2 weeks), whereas trying to archive
bugs during the
>     transition (proposal 3) will delay the transition for a while (likely
several months)
>     while we evaluate the various solutions for moving bugs from bugzilla
to GitHub.
> 
> 
>     The original proposal was to do 1 or 2, however there were some
concerns raised on the list
>     that having 2 different places to search for bugs for some period of
time would
>     be very inconvenient.  So, I would like to restart this discussion and
hopefully we can
>     come to some kind of conclusion about the best way forward.
> 
>     Thanks,
>     Tom
> 
>     _______________________________________________
>     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
>

> Can we preserve the existing bug numbers if we migrate this way? There are
lots of references to "PRxxxxx" in checked in LLVM artifacts and
elsewhere in the world, as well as links to llvm.org/PRxxxxx, and if we can
preserve all the issue numbers this would ease the transition pain
substantially.
Well... I hate to say this, but quite unlikely. Unfortunately, there
were significant changes in GitHub opensource team and these days they
are much less responsive than they used to be during our github
migration. I asked this question several times, and unfortunately,
there is no answer. I will certainly keep trying.

The problem here is there is no way to assign / control issue numbers
at all. They are just automatically assigned in sequential order.
While it might be possible to utilize this while migrating everything
to, say, a special archive project on GitHub, we will not be able to
control the numbers assigned should we migrate the issues one-by-one
or just move from archive to main project.

So, the only viable way seems to be plain big mapping from bugzilla to
github issue numbers without anything simple like "llvm.org/PRxxxxxx
becomes https://github.com/llvm/llvm-project/issues/xxxxxx".


--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

In a previous discussion, one other suggestion had been to migrate all the
bugzilla bugs to a separate initially-private "bug archive" repository
in
github. This has a few benefits:
1. If the migration is messed up, the repo can be deleted, and the process
run again, until we get a result we like.
2. The numbering can be fully-controlled.
Once the bugs are migrated to *some* github repository, individual issues
can then be "moved" between repositories, and github will redirect
from the
movefrom-repository's bug to the target repository's bug.

We could also just have llvm.org/PR### be the url only for legacy bugzilla
issue numbers -- and have it use a file listing the mappings of bugzilla id
-> github id to generate the redirects. (GCC just did this recently for svn
revision number redirections,
https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).

Then we could introduce a new naming scheme for github issue shortlinks.

On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I wanted to continue discussing the plan to migrate from Bugzilla to
>> Github.
>> It was suggested that I start a new thread and give a summary of the
>> proposal
>> and what has changed since it was originally proposed in October.
>>
>> == Here is the original proposal:
>>
>> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
>>
>> == What has changed:
>>
>> * You will be able to subscribe to notifications for a specific issue
>>   labels.  We have a proof of concept notification system using github
>> actions
>>   that will be used for this.
>>
>> * Emails will be sent to llvm-bugs when issues are opened or closed.
>>
>> * We have the initial list of labels:
>> https://github.com/llvm/llvm-project/labels
>>
>> == Remaining issue:
>>
>> * There is one remaining issue that I don't feel we have consensus
on,
>> and that is what to do with bugs in the existing bugzilla.  Here are
some
>> options
>> that we have discussed:
>>
>> 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla
>> that are
>> still active will be updated there until they are closed.  This means
>> that over
>> time the number of active bugs in bugzilla will slowly decrease as bugs
>> are closed
>> out.  Then at some point in the future, all of the bugs from bugzilla
>> will be archived
>> into their own GitHub repository that is separate from the llvm-project
>> repo.
>>
>> 2. Same as 1, but also create a migration script that would allow
anyone
>> to
>> manually migrate an active bug from bugzilla to a GitHub issue in the
>> llvm-project
>> repo.  The intention with this script is that it would be used to
migrate
>> high-traffic
>> or important bugs from bugzilla to GitHub to help increase the
visibility
>> of the bug.
>> This would not be used for mass migration of all the bugs.
>>
>> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
>> issues at the same time.
>> Closed or inactive bugs would be archived into their own GitHub
>> repository, and active bugs
>> would be migrated to the llvm-project repo.
>>
>
> Can we preserve the existing bug numbers if we migrate this way? There are
> lots of references to "PRxxxxx" in checked in LLVM artifacts and
elsewhere
> in the world, as well as links to llvm.org/PRxxxxx, and if we can
> preserve all the issue numbers this would ease the transition pain
> substantially.
>
>
>> The key difference between proposal 1,2 and 3, is when bugs will be
>> archived from bugzilla
>> to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means
that
>> we can migrate
>> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive
>> bugs during the
>> transition (proposal 3) will delay the transition for a while (likely
>> several months)
>> while we evaluate the various solutions for moving bugs from bugzilla
to
>> GitHub.
>>
>>
>> The original proposal was to do 1 or 2, however there were some
concerns
>> raised on the list
>> that having 2 different places to search for bugs for some period of
time
>> would
>> be very inconvenient.  So, I would like to restart this discussion and
>> hopefully we can
>> come to some kind of conclusion about the best way forward.
>>
>> Thanks,
>> Tom
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200420/5f3173bf/attachment-0001.html>

Hi,

How is the user workflow to file bugs? Do we have some sort of template? Do
they have to pick a label?

Thanks,

-- 
Mehdi


On Mon, Apr 20, 2020 at 12:30 PM Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I wanted to continue discussing the plan to migrate from Bugzilla to
> Github.
> It was suggested that I start a new thread and give a summary of the
> proposal
> and what has changed since it was originally proposed in October.
>
> == Here is the original proposal:
>
> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
>
> == What has changed:
>
> * You will be able to subscribe to notifications for a specific issue
>   labels.  We have a proof of concept notification system using github
> actions
>   that will be used for this.
>
> * Emails will be sent to llvm-bugs when issues are opened or closed.
>
> * We have the initial list of labels:
> https://github.com/llvm/llvm-project/labels
>
> == Remaining issue:
>
> * There is one remaining issue that I don't feel we have consensus on,
> and that is what to do with bugs in the existing bugzilla.  Here are some
> options
> that we have discussed:
>
> 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla that
> are
> still active will be updated there until they are closed.  This means that
> over
> time the number of active bugs in bugzilla will slowly decrease as bugs
> are closed
> out.  Then at some point in the future, all of the bugs from bugzilla will
> be archived
> into their own GitHub repository that is separate from the llvm-project
> repo.
>
> 2. Same as 1, but also create a migration script that would allow anyone to
> manually migrate an active bug from bugzilla to a GitHub issue in the
> llvm-project
> repo.  The intention with this script is that it would be used to migrate
> high-traffic
> or important bugs from bugzilla to GitHub to help increase the visibility
> of the bug.
> This would not be used for mass migration of all the bugs.
>
> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
> issues at the same time.
> Closed or inactive bugs would be archived into their own GitHub
> repository, and active bugs
> would be migrated to the llvm-project repo.
>
>
> The key difference between proposal 1,2 and 3, is when bugs will be
> archived from bugzilla
> to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that
> we can migrate
> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs
> during the
> transition (proposal 3) will delay the transition for a while (likely
> several months)
> while we evaluate the various solutions for moving bugs from bugzilla to
> GitHub.
>
>
> The original proposal was to do 1 or 2, however there were some concerns
> raised on the list
> that having 2 different places to search for bugs for some period of time
> would
> be very inconvenient.  So, I would like to restart this discussion and
> hopefully we can
> come to some kind of conclusion about the best way forward.
>
> Thanks,
> Tom
>
> _______________________________________________
> 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/20200420/aedab53b/attachment.html>

On 04/20/2020 09:15 PM, Mehdi AMINI wrote:
> Hi,
> 
> How is the user workflow to file bugs? Do we have some sort of template? Do
they have to pick a label?
> 
We don't have any templates defined yet, we need someone to volunteer to
do this.

Users would not be required to pick a label, they would either use a template
which would add the label automatically or pick a label they felt was relevant.

-Tom
> Thanks,
> 
> -- 
> Mehdi
> 
> 
> On Mon, Apr 20, 2020 at 12:30 PM Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>     Hi,
> 
>     I wanted to continue discussing the plan to migrate from Bugzilla to
Github.
>     It was suggested that I start a new thread and give a summary of the
proposal
>     and what has changed since it was originally proposed in October.
> 
>     == Here is the original proposal:
> 
>     http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
> 
>     == What has changed:
> 
>     * You will be able to subscribe to notifications for a specific issue
>       labels.  We have a proof of concept notification system using github
actions
>       that will be used for this.
> 
>     * Emails will be sent to llvm-bugs when issues are opened or closed.
> 
>     * We have the initial list of labels:
https://github.com/llvm/llvm-project/labels
> 
>     == Remaining issue:
> 
>     * There is one remaining issue that I don't feel we have consensus
on,
>     and that is what to do with bugs in the existing bugzilla.  Here are
some options
>     that we have discussed:
> 
>     1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla
that are
>     still active will be updated there until they are closed.  This means
that over
>     time the number of active bugs in bugzilla will slowly decrease as bugs
are closed
>     out.  Then at some point in the future, all of the bugs from bugzilla
will be archived
>     into their own GitHub repository that is separate from the llvm-project
repo.
> 
>     2. Same as 1, but also create a migration script that would allow
anyone to
>     manually migrate an active bug from bugzilla to a GitHub issue in the
llvm-project
>     repo.  The intention with this script is that it would be used to
migrate high-traffic
>     or important bugs from bugzilla to GitHub to help increase the
visibility of the bug.
>     This would not be used for mass migration of all the bugs.
> 
>     3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
issues at the same time.
>     Closed or inactive bugs would be archived into their own GitHub
repository, and active bugs
>     would be migrated to the llvm-project repo.
> 
> 
>     The key difference between proposal 1,2 and 3, is when bugs will be
archived from bugzilla
>     to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means
that we can migrate
>     to GitHub issues sooner (within 1-2 weeks), whereas trying to archive
bugs during the
>     transition (proposal 3) will delay the transition for a while (likely
several months)
>     while we evaluate the various solutions for moving bugs from bugzilla
to GitHub.
> 
> 
>     The original proposal was to do 1 or 2, however there were some
concerns raised on the list
>     that having 2 different places to search for bugs for some period of
time would
>     be very inconvenient.  So, I would like to restart this discussion and
hopefully we can
>     come to some kind of conclusion about the best way forward.
> 
>     Thanks,
>     Tom
> 
>     _______________________________________________
>     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
>

Please could we replace the "llvm-tools" with a single label for each
LLVM
tool (i.e. labels for llvm-ar, llvm-as, llvm-cxxfilt, llvm-objdump etc
etc). As mentioned on multiple occasions now, this is much more
user-friendly both for people filing issues, and for those like myself who
are only interested in certain tools within the tools directory. New bugs
can easily be attributed to the tool by finding the label that matches the
executable name. As for subscribing, there are many llvm-* tools that I am
not interested in because they have nothing to do with the toolchain my
company provides. Being subscribed to all bugs in relation to this simply
will result in me getting extra noise in my inbox, leading me to be more
inclined to ignore things and thus miss items that I'm actually interested
in. This will therefore reduce the volume of triage done, which in turn
will have a negative impact on the quality of the project (both in leaving
important bugs unaddressed and in disincentivising people from filing bugs
in this area in the future).

Just because a bugzilla component doesn't get high traffic doesn't mean
it
isn't useful.

Strong -1 to the migration until this has been addressed, as my previous
concerns seem to be being ignored.

See also http://lists.llvm.org/pipermail/llvm-dev/2018-November/127692.html
(why we shouldn't limit bugzilla components based on numbers of bugs
filed), and my thread here
http://lists.llvm.org/pipermail/llvm-dev/2020-March/139953.html (which
included discussions on triage groups, and how some of us are quite focused
on small areas, all of which are related).

Regards,

James

On Mon, 20 Apr 2020 at 20:31, Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I wanted to continue discussing the plan to migrate from Bugzilla to
> Github.
> It was suggested that I start a new thread and give a summary of the
> proposal
> and what has changed since it was originally proposed in October.
>
> == Here is the original proposal:
>
> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
>
> == What has changed:
>
> * You will be able to subscribe to notifications for a specific issue
>   labels.  We have a proof of concept notification system using github
> actions
>   that will be used for this.
>
> * Emails will be sent to llvm-bugs when issues are opened or closed.
>
> * We have the initial list of labels:
> https://github.com/llvm/llvm-project/labels
>
> == Remaining issue:
>
> * There is one remaining issue that I don't feel we have consensus on,
> and that is what to do with bugs in the existing bugzilla.  Here are some
> options
> that we have discussed:
>
> 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla that
> are
> still active will be updated there until they are closed.  This means that
> over
> time the number of active bugs in bugzilla will slowly decrease as bugs
> are closed
> out.  Then at some point in the future, all of the bugs from bugzilla will
> be archived
> into their own GitHub repository that is separate from the llvm-project
> repo.
>
> 2. Same as 1, but also create a migration script that would allow anyone to
> manually migrate an active bug from bugzilla to a GitHub issue in the
> llvm-project
> repo.  The intention with this script is that it would be used to migrate
> high-traffic
> or important bugs from bugzilla to GitHub to help increase the visibility
> of the bug.
> This would not be used for mass migration of all the bugs.
>
> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
> issues at the same time.
> Closed or inactive bugs would be archived into their own GitHub
> repository, and active bugs
> would be migrated to the llvm-project repo.
>
>
> The key difference between proposal 1,2 and 3, is when bugs will be
> archived from bugzilla
> to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that
> we can migrate
> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs
> during the
> transition (proposal 3) will delay the transition for a while (likely
> several months)
> while we evaluate the various solutions for moving bugs from bugzilla to
> GitHub.
>
>
> The original proposal was to do 1 or 2, however there were some concerns
> raised on the list
> that having 2 different places to search for bugs for some period of time
> would
> be very inconvenient.  So, I would like to restart this discussion and
> hopefully we can
> come to some kind of conclusion about the best way forward.
>
> Thanks,
> Tom
>
> _______________________________________________
> 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/20200421/646b8401/attachment.html>

Hi James,
> Please could we replace the "llvm-tools" with a single label for
each LLVM tool (i.e. labels for llvm-ar, llvm-as, llvm-cxxfilt, llvm-objdump etc
etc).
Sorry, I missed the subcomponents for the tools when I did the
migration of the labels. Will add them!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

clangd's experience using github issues to track bugs (in a separate repo)
has been very positive, and I'm glad you're pushing on this!

Part of this has been that our issue tracker has been scoped to our
subproject only, which is a scope that the tool works well for (on the user
and developer side).
As such I don't think we should migrate clangd to a using the monorepo
bugtracker. Email subscription to a label is better than nothing, but worse
than a separate repo.
Removing the clangd label from the monorepo bugtracker seems like the
simplest thing, though I'm happy to work on auto-moving bugs if that's
better.

(I'd suggest considering the same for other subprojects, though I know
that's not a popular opinion here)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200424/6a3b5c15/attachment.html>

On 04/24/2020 03:24 AM, Sam McCall wrote:
> clangd's experience using github issues to track bugs (in a separate
repo) has been very positive, and I'm glad you're pushing on this!
> 
> Part of this has been that our issue tracker has been scoped to our
subproject only, which is a scope that the tool works well for (on the user and
developer side).
> As such I don't think we should migrate clangd to a using the monorepo
bugtracker. Email subscription to a label is better than nothing, but worse than
a separate repo.
> Removing the clangd label from the monorepo bugtracker seems like the
simplest thing, though I'm happy to work on auto-moving bugs if that's
better.
> 
> (I'd suggest considering the same for other subprojects, though I know
that's not a popular opinion here)
I think it's important for everything in the monorepo to use the same bug
tracker.

There are advantages to having code in the monorepo (e.g. free
updates for API changes, a more consistent build experience, etc.).
But there are also costs, as you have pointed out, like having to use
a less than ideal bug tracker.  It's really up to sub-projects
to make the decision about whether these benefits are worth the costs.
The flang developers have just gone through this process and have
had to make some sacrifices to get the code in, but ultimately felt the
sacrifices were worth it.

I think it hurts the ability of developers and users to collaborate effectively,
if the infrastructure for the project is spread across too many different
places.
And good collaboration is key for a project of this size with some many tightly
connected components.

Getting back to the proposal we are discussing.  Do you have any specific
feedback
for improvements that might help make it align better with the kind of
experience
the clangd users and developers are looking for?

- Tom

Hi,

Thanks to everyone who provided feedback.  I would like to propose a
more detailed plan based on the everyone's comments.  It seems like there
was a strong
preference to maintain the bug ID numbers, so this proposal tries to address
that.

TLDR; This proposes to maintain bug ID numbers by overwriting existing GitHub
issues
instead of creating new ones.  e.g. github.com/llvm/llvm-project/issues/1 will
be overwritten with data from llvm.org/PR1.  There will be some bugs that
end up having their data copied into pull requests, which may be strange,
but the data will be preserved and the IDs will be preserved and this would
only happen to very old bugs.

Proposal:

Detailed steps for doing the migration:


* Weeks or days before the migration:

1. Create a new GitHub repository called llvm-bug-archive and import bug
data from bugzilla.

This step should not be under any kind of time pressure, so that the conversion
process can be debugged and refined.

2. Install label notification system using GitHub actions and enable web hook
to send emails to llvm-bugs list.

* Day before the migration:

3. Make bugzilla readonly.

4. Import any new bugs created since the last import.

There may be commit access disruption during the migration, so 
completing these steps the day before will limit the amount of down time.

5. Temporarily re-enable issues in the llvm-project repo and copy existing
issues
to the llvm-bug-archive repo so they get higher IDs numbers than any
existing PR.  Disable issues when done.

Note that we will copy issues instead of moving them, which means the original
issue will remain in tact.  This will allow us to retain the bug IDs
for future use and not 'lose' a bug ID.

* Day of migration:

6. Lockdown the repo as much as possible to prevent people from creating
issues or pull requests.

Temporarily making the repo private may be one way to achieve this.  Other
suggestions welcome.

7. Copy issues with overlapping issues IDs from the llvm-bug-archive repo
into the llvm-project repo.

Issues from the llvm-bug-archive repo that have the same ID number as
existing issues in the llvm-project repo will be manually copied from
the former to the later.  This will allow us to preserve the PR numbers
from bugzilla.  Here is an example for how this would work:

- Delete comments and description from llvm-project issue #1.
- Copy comments and description from llvm-bug-archive issue #1 into
  llvm-project issue #1.

Since GitHub issue and pull requests share the same numbering sequence, any
PR# from bugzilla that maps to a pull request in the llvm-project repo will
need to have it's comments copied into a pull request.  These issues will
look slightly
strange since there will be random commits attached to the issue.  However,
all data will be preserved and more importantly the bug ID will be preserved.

The issues URL can be used to access pull requests e.g.
pull request #84 is accessible via github.com/llvm/llvm-project/issues/84
so even with bugzilla data stored in pull requests, we will still be able to do
a simple redirect
from llvm.org/PR### to github.com/llvm/llvm-project/issues/###


8. Once all the overlapping Issue IDs have been copied.  Move the rest of the
issues
from the llvm-bug-archive repo to the llvm-project repo.

This should be faster than doing the copies since we do not need to overwrite
existing
issues and can just move the issues from one repo to the other.

The end result of this is that we have all the old bugs from bugzilla present as
issues
in the llvm-project repository with all of their ID numbers preserved.


* Other action items:

- We need volunteers to help create bug templates to simplify the process of
submitting
  bugs.  If you are interested in helping with this, let me know.

- Continue to iterate on the set of issue labels.  This should not block the
migration since
labels can be changed at any time, but there were some suggested improvements
that should
be discussed.


Please reply to this proposal with your questions, comments, praise, or
concerns.

Thanks,
Tom


[1]
https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates




On 04/20/2020 12:30 PM, Tom Stellard via llvm-dev wrote:
> Hi,
> 
> I wanted to continue discussing the plan to migrate from Bugzilla to
Github.
> It was suggested that I start a new thread and give a summary of the
proposal
> and what has changed since it was originally proposed in October.
> 
> == Here is the original proposal:
> 
> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
> 
> == What has changed:
> 
> * You will be able to subscribe to notifications for a specific issue
>   labels.  We have a proof of concept notification system using github
actions
>   that will be used for this.
> 
> * Emails will be sent to llvm-bugs when issues are opened or closed.
> 
> * We have the initial list of labels:
https://github.com/llvm/llvm-project/labels
> 
> == Remaining issue:
> 
> * There is one remaining issue that I don't feel we have consensus on,
> and that is what to do with bugs in the existing bugzilla.  Here are some
options
> that we have discussed:
> 
> 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla that
are
> still active will be updated there until they are closed.  This means that
over
> time the number of active bugs in bugzilla will slowly decrease as bugs are
closed
> out.  Then at some point in the future, all of the bugs from bugzilla will
be archived
> into their own GitHub repository that is separate from the llvm-project
repo.
> 
> 2. Same as 1, but also create a migration script that would allow anyone to
> manually migrate an active bug from bugzilla to a GitHub issue in the
llvm-project
> repo.  The intention with this script is that it would be used to migrate
high-traffic
> or important bugs from bugzilla to GitHub to help increase the visibility
of the bug.
> This would not be used for mass migration of all the bugs.
> 
> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub issues
at the same time.
> Closed or inactive bugs would be archived into their own GitHub repository,
and active bugs
> would be migrated to the llvm-project repo.
> 
> 
> The key difference between proposal 1,2 and 3, is when bugs will be
archived from bugzilla
> to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that
we can migrate
> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive bugs
during the
> transition (proposal 3) will delay the transition for a while (likely
several months)
> while we evaluate the various solutions for moving bugs from bugzilla to
GitHub.
> 
> 
> The original proposal was to do 1 or 2, however there were some concerns
raised on the list
> that having 2 different places to search for bugs for some period of time
would
> be very inconvenient.  So, I would like to restart this discussion and
hopefully we can
> come to some kind of conclusion about the best way forward.
> 
> Thanks,
> Tom
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

Generally sounds pretty good to me - only variation on the theme (&
certainly imho dealer's choice at this point - if you/whoever ends up doing
this doesn't like the sound of it, they shouldn't feel they have to do
it
this way) - maybe creating blank issues up to the current bugzilla PR
number (& maybe some padding) in a single/quick-ish (no idea how quickly
those can be created) window might help reduce the need for race
conditions/shutting down bug reporting, etc

On Wed, Apr 29, 2020 at 8:25 AM Tom Stellard via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Hi,
>
> Thanks to everyone who provided feedback.  I would like to propose a
> more detailed plan based on the everyone's comments.  It seems like
there
> was a strong
> preference to maintain the bug ID numbers, so this proposal tries to
> address that.
>
> TLDR; This proposes to maintain bug ID numbers by overwriting existing
> GitHub issues
> instead of creating new ones.  e.g. github.com/llvm/llvm-project/issues/1
> will
> be overwritten with data from llvm.org/PR1.  There will be some bugs that
> end up having their data copied into pull requests, which may be strange,
> but the data will be preserved and the IDs will be preserved and this would
> only happen to very old bugs.
>
> Proposal:
>
> Detailed steps for doing the migration:
>
>
> * Weeks or days before the migration:
>
> 1. Create a new GitHub repository called llvm-bug-archive and import bug
> data from bugzilla.
>
> This step should not be under any kind of time pressure, so that the
> conversion
> process can be debugged and refined.
>
> 2. Install label notification system using GitHub actions and enable web
> hook
> to send emails to llvm-bugs list.
>
> * Day before the migration:
>
> 3. Make bugzilla readonly.
>
> 4. Import any new bugs created since the last import.
>
> There may be commit access disruption during the migration, so
> completing these steps the day before will limit the amount of down time.
>
> 5. Temporarily re-enable issues in the llvm-project repo and copy existing
> issues
> to the llvm-bug-archive repo so they get higher IDs numbers than any
> existing PR.  Disable issues when done.
>
> Note that we will copy issues instead of moving them, which means the
> original
> issue will remain in tact.  This will allow us to retain the bug IDs
> for future use and not 'lose' a bug ID.
>
> * Day of migration:
>
> 6. Lockdown the repo as much as possible to prevent people from creating
> issues or pull requests.
>
> Temporarily making the repo private may be one way to achieve this.  Other
> suggestions welcome.
>
> 7. Copy issues with overlapping issues IDs from the llvm-bug-archive repo
> into the llvm-project repo.
>
> Issues from the llvm-bug-archive repo that have the same ID number as
> existing issues in the llvm-project repo will be manually copied from
> the former to the later.  This will allow us to preserve the PR numbers
> from bugzilla.  Here is an example for how this would work:
>
> - Delete comments and description from llvm-project issue #1.
> - Copy comments and description from llvm-bug-archive issue #1 into
>   llvm-project issue #1.
>
> Since GitHub issue and pull requests share the same numbering sequence, any
> PR# from bugzilla that maps to a pull request in the llvm-project repo will
> need to have it's comments copied into a pull request.  These issues
will
> look slightly
> strange since there will be random commits attached to the issue.  However,
> all data will be preserved and more importantly the bug ID will be
> preserved.
>
> The issues URL can be used to access pull requests e.g.
> pull request #84 is accessible via github.com/llvm/llvm-project/issues/84
> so even with bugzilla data stored in pull requests, we will still be able
> to do a simple redirect
> from llvm.org/PR### <http://llvm.org/PR#%23%23> to
> github.com/llvm/llvm-project/issues/###
> <http://github.com/llvm/llvm-project/issues/#%23%23>
>
>
> 8. Once all the overlapping Issue IDs have been copied.  Move the rest of
> the issues
> from the llvm-bug-archive repo to the llvm-project repo.
>
> This should be faster than doing the copies since we do not need to
> overwrite existing
> issues and can just move the issues from one repo to the other.
>
> The end result of this is that we have all the old bugs from bugzilla
> present as issues
> in the llvm-project repository with all of their ID numbers preserved.
>
>
> * Other action items:
>
> - We need volunteers to help create bug templates to simplify the process
> of submitting
>   bugs.  If you are interested in helping with this, let me know.
>
> - Continue to iterate on the set of issue labels.  This should not block
> the migration since
> labels can be changed at any time, but there were some suggested
> improvements that should
> be discussed.
>
>
> Please reply to this proposal with your questions, comments, praise, or
> concerns.
>
> Thanks,
> Tom
>
>
> [1]
>
https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates
>
>
>
>
> On 04/20/2020 12:30 PM, Tom Stellard via llvm-dev wrote:
> > Hi,
> >
> > I wanted to continue discussing the plan to migrate from Bugzilla to
> Github.
> > It was suggested that I start a new thread and give a summary of the
> proposal
> > and what has changed since it was originally proposed in October.
> >
> > == Here is the original proposal:
> >
> > http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
> >
> > == What has changed:
> >
> > * You will be able to subscribe to notifications for a specific issue
> >   labels.  We have a proof of concept notification system using github
> actions
> >   that will be used for this.
> >
> > * Emails will be sent to llvm-bugs when issues are opened or closed.
> >
> > * We have the initial list of labels:
> https://github.com/llvm/llvm-project/labels
> >
> > == Remaining issue:
> >
> > * There is one remaining issue that I don't feel we have consensus
on,
> > and that is what to do with bugs in the existing bugzilla.  Here are
> some options
> > that we have discussed:
> >
> > 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla
> that are
> > still active will be updated there until they are closed.  This means
> that over
> > time the number of active bugs in bugzilla will slowly decrease as
bugs
> are closed
> > out.  Then at some point in the future, all of the bugs from bugzilla
> will be archived
> > into their own GitHub repository that is separate from the
llvm-project
> repo.
> >
> > 2. Same as 1, but also create a migration script that would allow
anyone
> to
> > manually migrate an active bug from bugzilla to a GitHub issue in the
> llvm-project
> > repo.  The intention with this script is that it would be used to
> migrate high-traffic
> > or important bugs from bugzilla to GitHub to help increase the
> visibility of the bug.
> > This would not be used for mass migration of all the bugs.
> >
> > 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
> issues at the same time.
> > Closed or inactive bugs would be archived into their own GitHub
> repository, and active bugs
> > would be migrated to the llvm-project repo.
> >
> >
> > The key difference between proposal 1,2 and 3, is when bugs will be
> archived from bugzilla
> > to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means
> that we can migrate
> > to GitHub issues sooner (within 1-2 weeks), whereas trying to archive
> bugs during the
> > transition (proposal 3) will delay the transition for a while (likely
> several months)
> > while we evaluate the various solutions for moving bugs from bugzilla
to
> GitHub.
> >
> >
> > The original proposal was to do 1 or 2, however there were some
concerns
> raised on the list
> > that having 2 different places to search for bugs for some period of
> time would
> > be very inconvenient.  So, I would like to restart this discussion and
> hopefully we can
> > come to some kind of conclusion about the best way forward.
> >
> > Thanks,
> > Tom
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200429/e5948c09/attachment.html>