Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

> On 04/20/2020 04:08 PM, James Y Knight 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.
> This seems like a good approach to me.
This might work, yes.

There are some limitations as well, this is why I'm very cautious
here. See 
https://docs.google.com/document/d/1byEcbsxF3pL-HGGd_K6axdh87tbcsuJK3Dp6ThxGjKA/edit
for some list.

>
> > 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).
> >
>
> Would we even need a mapping file for this if we are able to get bugzilla id N
> to be archived to GitHub issue id N?
>
> -Tom
>
> > 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 
> > mailto:llvm-...@lists.llvm.org>> wrote:
> >
> > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev 
> > mailto:llvm-...@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 "PRx" in checked in LLVM artifacts and 
> > elsewhere in the world, as well as links to llvm.org/PRx 
> > , 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 prop

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[James Henderson via lldb-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-...@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-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[David Blaikie via lldb-dev]

All things being equal, I'd prefer Richard Smith's proposal that doesn't
involve needing a new/old numbering scheme, but lets us keep a single
numbering/redirection (& I doubt we need the first 200 bugs in any case -
has anyone referred to bugs that early in the last 5 years, say? But
wouldn't mind if they were copied in with different numbers/some kind of
redirection (but hey, if we can rewrite bug contents - we could always move
the existing 200 bugs (but I guess some are pull requests and we can't
totally rewrite those into bugs?) up into the new numbering range once the
necessary numbers are reserved)).

But I understand the single numbering preserving option is likely more
complicated/costly & thus not an equal candidate - just my minor preference.

On Mon, Apr 20, 2020 at 9:58 PM Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 04/20/2020 04:08 PM, James Y Knight 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.
> >
>
> This seems like a good approach to me.
>
> > We could also just have llvm.org/PR###  <
> http://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).
> >
>
> Would we even need a mapping file for this if we are able to get bugzilla
> id N
> to be archived to GitHub issue id N?
>
> -Tom
>
> > 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-...@lists.llvm.org > wrote:
> >
> > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
> llvm-...@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 "PRx" in checked in LLVM artifacts and
> elsewhere in the world, as well as links to llvm.org/PRx <
> http://llvm.org/PRx>, and if we can

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Philip Reames via lldb-dev]

+1 to James's take

I'd prefer simplicity of implementation over perfection here.

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###  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 
mailto:llvm-...@lists.llvm.org>> wrote:


On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev
mailto:llvm-...@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 "PRx" in checked in LLVM
artifacts and elsewhere in the world, as well as links to
llvm.org/PRx , 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
 

[lldb-dev] LLVM 10.0.1 Release Schedule

[Tom Stellard via lldb-dev]

Hi,

Here is the proposed 10.0.1 release schedule.  If there are
no objections, I'll put it on the website.

May 18: 10.0.1-rc1
Jun 18: 10.0.1-rc2
Jun 25: 10.0.1-final

-Tom

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Richard Smith via lldb-dev]

On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <
cfe-...@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.

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###  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-...@lists.llvm.org> wrote:
>
>> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
>> llvm-...@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 "PRx" in checked in LLVM artifac

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Philip Reames via lldb-dev]

On 4/21/20 3:36 PM, Richard Smith wrote:
On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev 
mailto:cfe-...@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.


I used to think this was super important, but I've now been through a 
couple of conversions which didn't provide a 1-to-1 mapping.  It's 
annoying for about 6 months, and after that, you basically forget it 
happened.  As long as old bugs are searchable in the new system, and you 
can find the new ID from the old system, the exact identifier isn't as 
important.


Anyways, this is all subjective and I'm certainty not volunteering to 
work on this, so IMHO my own opinion doesn't really count.  :)





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.


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###
 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
mailto:llvm-...@lists.llvm.org>> wrote:

On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev
mailto:llvm-...@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 

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Tom Stellard via lldb-dev]

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 
> mailto:cfe-...@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?

-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###  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 
>> mailto:llvm-...@lists.llvm.org>> wrote:
>>
>> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev 
>> mailto:llvm-...@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 
>

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Richard Smith via lldb-dev]

On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> 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-...@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?


These numbers appear all over our codebase. PR[0-9] appears 3592 times in
Clang testcases, plus 45 times in Clang source code and 119 times more as
the file names of Clang testcases. If we add inconvenience to looking up
all of those, that makes maintenance harder each time someone wants to look
one of those up. (That's probably a ~weekly occurrence for me.)

Also, bug numbers appear in other bugs. I would assume we're not going to
be able to reliably figure out which numbers appearing in a bug are bug
numbers during the import process, so those numbers will persist into the
github issues world.

(In addition, I'm sure multiple groups have their own tracking systems, web
pages, documentation, etc. that contain references to LLVM PR numbers. But
maybe we shouldn't worry too much about that.)

Could you help give some example use cases that require having
> a non-intersecting set of bug numbers for bugzilla bugs and github issues?
>

It makes conversing about bug numbers more difficult if you need to clarify
which system you're talking about. As a minor example, we'd have to avoid
saying "PR" for the new system in order to avoid confusion, and get used to
some new terminology, and probably not use "bug 1234" to describe either
system, because that would be ambiguous. None of these individual factors
seems like a huge disruption, but they all seem like inconvenience
we should prefer to avoid if possible.

-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### 
>  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-...@lists.llvm.org > wrote:
> >>
> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
> llvm-...@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.
> >>
> >>