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

On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
> On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
>> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>      +1 to James's take
>>
>>      I'd prefer simplicity of implementation over perfection here.
>>
>> If we end up with two different bug numbering systems, that's a
problem that we will be paying for for many years. It's worth some
investment now to avoid that problem. And it doesn't seem like it really
requires much investment.
>>
>> Here's another path we could take:
>>
>> 1) Fork the llvm repository to a private "bugs" repository.
Mirror the bugzilla issues there. Iterate until we're happy, as per
James's proposal.
>> 2) Sync the forked repository to the llvm repository, delete the llvm
repository, rename "bugs" to "llvm", and make it public.
>>
>> Then we'll have the first N bugs in llvm-project/llvm being
*exactly* the bugzilla bugs, and we'll have excised the existing github
issues that we want to pretend never existed anyway.
>>
>>
>> I think we've missed an important step in the planning here:
we've not agreed on a set of goals for the transition. Here are mine:
>>
>>   * We end up with one single issue tracking system containing all
issues, both old and new, both open and closed.
>>   * All links and references to existing bugs still work.
>>   * We have a single bug numbering system covering all bugs, and old
bugs retain their numbers.
> Why are the bug numbers important?  Could you help give some example use
cases that require having
> a non-intersecting set of bug numbers for bugzilla bugs and github issues?

While I have no experience in bugzilla or github tooling, the two step 
process described by Richard doesn't seem to be very complicated.


As mentioned by others, we have commits and tests (and sometimes source 
files) that explicitly mention bug numbers. I do regularly look up bugs 
from a decade ago to determine if a test or some code still has 
relevance or not. If PR3214 can be one of two bugs, it does not only 
increase lookup time but also add confusion to everyone involved.


Cheers,

   Johannes


> -Tom
>
>
>> It sounds like we don't all agree that the last point is important,
but if we can achieve it without any significant additional cost, why not do so?
>>
>>      Philip
>>
>>      On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
>>>      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###
<http://llvm.org/PR#%23%23> 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 <mailto: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 <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.
>>>           
>>>
>>>              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
>>>
>>>          _______________________________________________
>>>          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
>>>
>>>
>>>      _______________________________________________
>>>      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
>> 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

Similar to other people's experiences, I've worked on a common code base
that supported three different platforms, and each platform used a
different bugzilla with it's own numbering scheme. I regularly came across
references to "BZ123456" with no indication as to which of the three
systems that referred to. This would often mean having to go to each in
turn and seeing if the corresponding bug looked like it had anything to do
with the related topic. Fortunately, given that there were many other
things using the same bugzilla instances, this was usually pretty clear,
but not always. Typos in bug numbers sometimes made things even harder,
since you had to spend three times as long trying to guess.

In other words +1 to using unique numbers, however we do it.

On Wed, 22 Apr 2020 at 03:44, Johannes Doerfert via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
wrote:
> >>
> >>      +1 to James's take
> >>
> >>      I'd prefer simplicity of implementation over perfection
here.
> >>
> >> If we end up with two different bug numbering systems, that's
a problem
> that we will be paying for for many years. It's worth some investment
now
> to avoid that problem. And it doesn't seem like it really requires much
> investment.
> >>
> >> Here's another path we could take:
> >>
> >> 1) Fork the llvm repository to a private "bugs"
repository. Mirror the
> bugzilla issues there. Iterate until we're happy, as per James's
proposal.
> >> 2) Sync the forked repository to the llvm repository, delete the
llvm
> repository, rename "bugs" to "llvm", and make it
public.
> >>
> >> Then we'll have the first N bugs in llvm-project/llvm being
*exactly*
> the bugzilla bugs, and we'll have excised the existing github issues
that
> we want to pretend never existed anyway.
> >>
> >>
> >> I think we've missed an important step in the planning here:
we've not
> agreed on a set of goals for the transition. Here are mine:
> >>
> >>   * We end up with one single issue tracking system containing all
> issues, both old and new, both open and closed.
> >>   * All links and references to existing bugs still work.
> >>   * We have a single bug numbering system covering all bugs, and
old
> bugs retain their numbers.
> > Why are the bug numbers important?  Could you help give some example
use
> cases that require having
> > a non-intersecting set of bug numbers for bugzilla bugs and github
> issues?
>
>
> While I have no experience in bugzilla or github tooling, the two step
> process described by Richard doesn't seem to be very complicated.
>
>
> As mentioned by others, we have commits and tests (and sometimes source
> files) that explicitly mention bug numbers. I do regularly look up bugs
> from a decade ago to determine if a test or some code still has
> relevance or not. If PR3214 can be one of two bugs, it does not only
> increase lookup time but also add confusion to everyone involved.
>
>
> Cheers,
>
>    Johannes
>
>
>
> > -Tom
> >
> >
> >> It sounds like we don't all agree that the last point is
important, but
> if we can achieve it without any significant additional cost, why not do
so?
> >>
> >>      Philip
> >>
> >>      On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
> >>>      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###
> <http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> 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 <mailto: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 <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.
> >>>
> >>>
> >>>              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
> >>>
> >>>          _______________________________________________
> >>>          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
> >>>
> >>>
> >>>      _______________________________________________
> >>>      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
> >> 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
> _______________________________________________
> 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/20200422/362441ed/attachment-0001.html>

Since Bugzilla numbers are all under 50,000 (at least for now:), can't we
simply bump the GitHub issue/pull request numbers to 50,000, and start from
there?

Then it would be easy to identify: < 50000 means Bugzilla, >= 50000 means
GitHub.

Now somebody's only gotta find a way to file 50000-200 bogus GitHub tickets.
:)  (Or ask GitHub support to bump the number synthetically.)

-Dimitry
> On 22 Apr 2020, at 09:10, James Henderson via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 
> Similar to other people's experiences, I've worked on a common code
base that supported three different platforms, and each platform used a
different bugzilla with it's own numbering scheme. I regularly came across
references to "BZ123456" with no indication as to which of the three
systems that referred to. This would often mean having to go to each in turn and
seeing if the corresponding bug looked like it had anything to do with the
related topic. Fortunately, given that there were many other things using the
same bugzilla instances, this was usually pretty clear, but not always. Typos in
bug numbers sometimes made things even harder, since you had to spend three
times as long trying to guess.
> 
> In other words +1 to using unique numbers, however we do it.
> 
> On Wed, 22 Apr 2020 at 03:44, Johannes Doerfert via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> 
> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev
<cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
<mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at
lists.llvm.org>>> wrote:
> >>
> >>      +1 to James's take
> >>
> >>      I'd prefer simplicity of implementation over perfection
here.
> >>
> >> If we end up with two different bug numbering systems, that's
a problem that we will be paying for for many years. It's worth some
investment now to avoid that problem. And it doesn't seem like it really
requires much investment.
> >>
> >> Here's another path we could take:
> >>
> >> 1) Fork the llvm repository to a private "bugs"
repository. Mirror the bugzilla issues there. Iterate until we're happy, as
per James's proposal.
> >> 2) Sync the forked repository to the llvm repository, delete the
llvm repository, rename "bugs" to "llvm", and make it
public.
> >>
> >> Then we'll have the first N bugs in llvm-project/llvm being
*exactly* the bugzilla bugs, and we'll have excised the existing github
issues that we want to pretend never existed anyway.
> >>
> >>
> >> I think we've missed an important step in the planning here:
we've not agreed on a set of goals for the transition. Here are mine:
> >>
> >>   * We end up with one single issue tracking system containing all
issues, both old and new, both open and closed.
> >>   * All links and references to existing bugs still work.
> >>   * We have a single bug numbering system covering all bugs, and
old bugs retain their numbers.
> > Why are the bug numbers important?  Could you help give some example
use cases that require having
> > a non-intersecting set of bug numbers for bugzilla bugs and github
issues?
> 
> 
> While I have no experience in bugzilla or github tooling, the two step
> process described by Richard doesn't seem to be very complicated.
> 
> 
> As mentioned by others, we have commits and tests (and sometimes source
> files) that explicitly mention bug numbers. I do regularly look up bugs
> from a decade ago to determine if a test or some code still has
> relevance or not. If PR3214 can be one of two bugs, it does not only
> increase lookup time but also add confusion to everyone involved.
> 
> 
> Cheers,
> 
>    Johannes
> 
> 
> 
> > -Tom
> >
> >
> >> It sounds like we don't all agree that the last point is
important, but if we can achieve it without any significant additional cost, why
not do so?
> >>
> >>      Philip
> >>
> >>      On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
> >>>      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###
<http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23
<http://llvm.org/PR#%23%23>> 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
<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 <mailto:llvm-dev at
lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto: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 <mailto:llvm-dev at
lists.llvm.org> <mailto: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
<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
<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> <http://llvm.org/PRxxxxx
<http://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 <mailto:llvm-dev at
lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
> >>>             
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >>>
> >>>          _______________________________________________
> >>>          LLVM Developers mailing list
> >>>          llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
> >>>         
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >>>
> >>>
> >>>      _______________________________________________
> >>>      LLVM Developers mailing list
> >>>      llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
> >>>      https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at
lists.llvm.org>>
> >>      https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<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
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-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
<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
<https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-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/20200422/49db65ec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/49db65ec/attachment.sig>

GitHub canonically uses "#NNN" to refer to its bugs or pull requests,
and
also supports "GH-NNN". We'll want to switch to one of those
schemes, so
that automatic linking works properly. So, in that case, PR1234 == legacy
issue, #1234 or GH-1234 == new issue.

(See
https://help.github.com/en/github/writing-on-github/autolinked-references-and-urls
)

On Tue, Apr 21, 2020, 10:43 PM Johannes Doerfert via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
wrote:
> >>
> >>      +1 to James's take
> >>
> >>      I'd prefer simplicity of implementation over perfection
here.
> >>
> >> If we end up with two different bug numbering systems, that's
a problem
> that we will be paying for for many years. It's worth some investment
now
> to avoid that problem. And it doesn't seem like it really requires much
> investment.
> >>
> >> Here's another path we could take:
> >>
> >> 1) Fork the llvm repository to a private "bugs"
repository. Mirror the
> bugzilla issues there. Iterate until we're happy, as per James's
proposal.
> >> 2) Sync the forked repository to the llvm repository, delete the
llvm
> repository, rename "bugs" to "llvm", and make it
public.
> >>
> >> Then we'll have the first N bugs in llvm-project/llvm being
*exactly*
> the bugzilla bugs, and we'll have excised the existing github issues
that
> we want to pretend never existed anyway.
> >>
> >>
> >> I think we've missed an important step in the planning here:
we've not
> agreed on a set of goals for the transition. Here are mine:
> >>
> >>   * We end up with one single issue tracking system containing all
> issues, both old and new, both open and closed.
> >>   * All links and references to existing bugs still work.
> >>   * We have a single bug numbering system covering all bugs, and
old
> bugs retain their numbers.
> > Why are the bug numbers important?  Could you help give some example
use
> cases that require having
> > a non-intersecting set of bug numbers for bugzilla bugs and github
> issues?
>
>
> While I have no experience in bugzilla or github tooling, the two step
> process described by Richard doesn't seem to be very complicated.
>
>
> As mentioned by others, we have commits and tests (and sometimes source
> files) that explicitly mention bug numbers. I do regularly look up bugs
> from a decade ago to determine if a test or some code still has
> relevance or not. If PR3214 can be one of two bugs, it does not only
> increase lookup time but also add confusion to everyone involved.
>
>
> Cheers,
>
>    Johannes
>
>
>
> > -Tom
> >
> >
> >> It sounds like we don't all agree that the last point is
important, but
> if we can achieve it without any significant additional cost, why not do
so?
> >>
> >>      Philip
> >>
> >>      On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
> >>>      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###
> <http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> 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 <mailto: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 <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.
> >>>
> >>>
> >>>              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
> >>>
> >>>          _______________________________________________
> >>>          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
> >>>
> >>>
> >>>      _______________________________________________
> >>>      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
> >> 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
> _______________________________________________
> 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/20200422/6586eac6/attachment.html>

GitHub also supports custom prefixes for the issues. However, here is
another limitation: the prefix must be at least 3 letters, so we
cannot, for example, autolink PR1234 issues. Already asked whether
this restriction could be lifted.

On Wed, Apr 22, 2020 at 3:15 PM James Y Knight via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> GitHub canonically uses "#NNN" to refer to its bugs or pull
requests, and also supports "GH-NNN". We'll want to switch to one
of those schemes, so that automatic linking works properly. So, in that case,
PR1234 == legacy issue, #1234 or GH-1234 == new issue.
>
> (See
https://help.github.com/en/github/writing-on-github/autolinked-references-and-urls)
>
> On Tue, Apr 21, 2020, 10:43 PM Johannes Doerfert via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
>>
>>
>> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
>> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
>> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev
<cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
wrote:
>> >>
>> >>      +1 to James's take
>> >>
>> >>      I'd prefer simplicity of implementation over
perfection here.
>> >>
>> >> If we end up with two different bug numbering systems,
that's a problem that we will be paying for for many years. It's worth
some investment now to avoid that problem. And it doesn't seem like it
really requires much investment.
>> >>
>> >> Here's another path we could take:
>> >>
>> >> 1) Fork the llvm repository to a private "bugs"
repository. Mirror the bugzilla issues there. Iterate until we're happy, as
per James's proposal.
>> >> 2) Sync the forked repository to the llvm repository, delete
the llvm repository, rename "bugs" to "llvm", and make it
public.
>> >>
>> >> Then we'll have the first N bugs in llvm-project/llvm
being *exactly* the bugzilla bugs, and we'll have excised the existing
github issues that we want to pretend never existed anyway.
>> >>
>> >>
>> >> I think we've missed an important step in the planning
here: we've not agreed on a set of goals for the transition. Here are mine:
>> >>
>> >>   * We end up with one single issue tracking system containing
all issues, both old and new, both open and closed.
>> >>   * All links and references to existing bugs still work.
>> >>   * We have a single bug numbering system covering all bugs,
and old bugs retain their numbers.
>> > Why are the bug numbers important?  Could you help give some
example use cases that require having
>> > a non-intersecting set of bug numbers for bugzilla bugs and github
issues?
>>
>>
>> While I have no experience in bugzilla or github tooling, the two step
>> process described by Richard doesn't seem to be very complicated.
>>
>>
>> As mentioned by others, we have commits and tests (and sometimes source
>> files) that explicitly mention bug numbers. I do regularly look up bugs
>> from a decade ago to determine if a test or some code still has
>> relevance or not. If PR3214 can be one of two bugs, it does not only
>> increase lookup time but also add confusion to everyone involved.
>>
>>
>> Cheers,
>>
>>    Johannes
>>
>>
>>
>> > -Tom
>> >
>> >
>> >> It sounds like we don't all agree that the last point is
important, but if we can achieve it without any significant additional cost, why
not do so?
>> >>
>> >>      Philip
>> >>
>> >>      On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
>> >>>      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###
<http://llvm.org/PR#%23%23> 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 <mailto: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 <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.
>> >>>
>> >>>
>> >>>              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
>> >>>
>> >>>          _______________________________________________
>> >>>          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
>> >>>
>> >>>
>> >>>      _______________________________________________
>> >>>      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
>> >> 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
>> _______________________________________________
>> 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


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

Github may do things in a canonical way, but I think you'll find that lots
of people will refer to them by other means in review comments, email
threads, etc. Let's avoid any risk of ambiguity...

Also, there's no guarantee in the future that Github won't decide to
start
auto-linking PR1234 as well, which would just get even more confusing.

On Wed, 22 Apr 2020 at 13:14, James Y Knight via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> GitHub canonically uses "#NNN" to refer to its bugs or pull
requests, and
> also supports "GH-NNN". We'll want to switch to one of those
schemes, so
> that automatic linking works properly. So, in that case, PR1234 == legacy
> issue, #1234 or GH-1234 == new issue.
>
> (See
>
https://help.github.com/en/github/writing-on-github/autolinked-references-and-urls
> )
>
> On Tue, Apr 21, 2020, 10:43 PM Johannes Doerfert via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>>
>> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
>> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
>> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
wrote:
>> >>
>> >>      +1 to James's take
>> >>
>> >>      I'd prefer simplicity of implementation over
perfection here.
>> >>
>> >> If we end up with two different bug numbering systems,
that's a
>> problem that we will be paying for for many years. It's worth some
>> investment now to avoid that problem. And it doesn't seem like it
really
>> requires much investment.
>> >>
>> >> Here's another path we could take:
>> >>
>> >> 1) Fork the llvm repository to a private "bugs"
repository. Mirror the
>> bugzilla issues there. Iterate until we're happy, as per
James's proposal.
>> >> 2) Sync the forked repository to the llvm repository, delete
the llvm
>> repository, rename "bugs" to "llvm", and make it
public.
>> >>
>> >> Then we'll have the first N bugs in llvm-project/llvm
being *exactly*
>> the bugzilla bugs, and we'll have excised the existing github
issues that
>> we want to pretend never existed anyway.
>> >>
>> >>
>> >> I think we've missed an important step in the planning
here: we've not
>> agreed on a set of goals for the transition. Here are mine:
>> >>
>> >>   * We end up with one single issue tracking system containing
all
>> issues, both old and new, both open and closed.
>> >>   * All links and references to existing bugs still work.
>> >>   * We have a single bug numbering system covering all bugs,
and old
>> bugs retain their numbers.
>> > Why are the bug numbers important?  Could you help give some
example
>> use cases that require having
>> > a non-intersecting set of bug numbers for bugzilla bugs and github
>> issues?
>>
>>
>> While I have no experience in bugzilla or github tooling, the two step
>> process described by Richard doesn't seem to be very complicated.
>>
>>
>> As mentioned by others, we have commits and tests (and sometimes source
>> files) that explicitly mention bug numbers. I do regularly look up bugs
>> from a decade ago to determine if a test or some code still has
>> relevance or not. If PR3214 can be one of two bugs, it does not only
>> increase lookup time but also add confusion to everyone involved.
>>
>>
>> Cheers,
>>
>>    Johannes
>>
>>
>>
>> > -Tom
>> >
>> >
>> >> It sounds like we don't all agree that the last point is
important,
>> but if we can achieve it without any significant additional cost, why
not
>> do so?
>> >>
>> >>      Philip
>> >>
>> >>      On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
>> >>>      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###
>> <http://llvm.org/PR#%23%23> <http://llvm.org/PR#%23%23> 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 <mailto: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 <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.
>> >>>
>> >>>
>> >>>              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
>> >>>
>> >>>          _______________________________________________
>> >>>          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
>> >>>
>> >>>
>> >>>      _______________________________________________
>> >>>      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
>> >> 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
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200422/bbc3b908/attachment-0001.html>