<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 4/22/20 2:35 PM, Richard Smith
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOfiQqnW2QUVAvmW8N4JBiEW88LWJy=4UahGFp1S-WAQB145fw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Wed, 22 Apr 2020 at 09:45, Philip Reames via
cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a>> wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>On 4/21/20 6:50 PM, Richard Smith wrote:<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Tue, 21 Apr 2020 at 17:00, Tom
Stellard via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On 04/21/2020
03:36 PM, Richard Smith via llvm-dev wrote:<br>
> On Tue, 21 Apr 2020 at 11:04, Philip Reames
via cfe-dev <<a
href="mailto:cfe-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
<mailto:<a href="mailto:cfe-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>>
wrote:<br>
> <br>
> +1 to James's take<br>
> <br>
> I'd prefer simplicity of implementation
over perfection here.<br>
> <br>
> 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.<br>
> <br>
> Here's another path we could take:<br>
> <br>
> 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.<br>
> 2) Sync the forked repository to the llvm
repository, delete the llvm repository, rename
"bugs" to "llvm", and make it public.<br>
> <br>
> 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.<br>
> <br>
> <br>
> 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:<br>
> <br>
> * We end up with one single issue tracking
system containing all issues, both old and new,
both open and closed.<br>
> * All links and references to existing bugs
still work.<br>
> * We have a single bug numbering system
covering all bugs, and old bugs retain their
numbers.<br>
<br>
Why are the bug numbers important?</blockquote>
<div><br>
</div>
<div>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.)</div>
</div>
</div>
</blockquote>
<p>For this use case, a simple script and bulk change to
update references in source repo means the numbering can
change arbitrarily. ~4k small mechanical changes is
just not that much to review for a one time update
assuming you trust the number remapping script and are
just looking for overly aggressive regex matches.<br>
</p>
</div>
</blockquote>
<div>It's not quite as straightforward as you're suggesting:
such a simple script would break a bunch of our CodeGen
tests that match mangled names, if the length of any bug
identifier changes. A grep for '_Z.*PR[0-9]' indicates that
there are at least 254 of those that might need manual
updating if we took this path.</div>
</div>
</div>
</blockquote>
We have an auto-updater for most llc scripts, but point taken. My
main point was this was one time, not that the one time was
trivial. <br>
<blockquote type="cite"
cite="mid:CAOfiQqnW2QUVAvmW8N4JBiEW88LWJy=4UahGFp1S-WAQB145fw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>(I don't have any quick fixes for your other mentioned
cases.)</p>
</div>
</blockquote>
<div>Another case I didn't think of before, but that seems
very important: bug numbers appear in commit messages, and
are primary context in understanding what the commit is
doing and why. [We *could* go on a bulk history editing
spree to fix those commit messages up (git filter-branch
actually makes this fairly easy) -- but that too would
create a little churn as everyone would needs to rebase all
their work in progress on the rewritten master, and
honestly, that sounds a lot scarier than any of the other
things we've considered in this thread :)]</div>
</div>
</div>
</blockquote>
Agreed, history rewrite as a solution here should be rejected out of
hand. :)<br>
<blockquote type="cite"
cite="mid:CAOfiQqnW2QUVAvmW8N4JBiEW88LWJy=4UahGFp1S-WAQB145fw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>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.</div>
<div><br>
</div>
<div>(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.)</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Could you help
give some example use cases that require having<br>
a non-intersecting set of bug numbers for bugzilla
bugs and github issues?<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> -Tom<br>
<br>
<br>
> <br>
> 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?<br>
> <br>
> Philip<br>
> <br>
> On 4/20/20 4:08 PM, James Y Knight via
llvm-dev wrote:<br>
>> 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:<br>
>> 1. If the migration is messed up, the
repo can be deleted, and the process run again,
until we get a result we like.<br>
>> 2. The numbering can be
fully-controlled.<br>
>> 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.<br>
>><br>
>> We could also just have <a
href="http://llvm.org/PR#%23%23"
rel="noreferrer" target="_blank"
moz-do-not-send="true">llvm.org/PR###</a> <<a
href="http://llvm.org/PR#%23%23"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://llvm.org/PR#%23%23</a>>
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, <a
href="https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html</a>).<br>
>><br>
>> Then we could introduce a new naming
scheme for github issue shortlinks.<br>
>><br>
>> On Mon, Apr 20, 2020 at 3:50 PM
Richard Smith via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>>
wrote:<br>
>><br>
>> On Mon, 20 Apr 2020 at 12:31, Tom
Stellard via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>>
wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I wanted to continue
discussing the plan to migrate from Bugzilla to
Github.<br>
>> It was suggested that I start
a new thread and give a summary of the proposal<br>
>> and what has changed since it
was originally proposed in October.<br>
>><br>
>> == Here is the original
proposal:<br>
>><br>
>> <a
href="http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html</a><br>
>><br>
>> == What has changed:<br>
>><br>
>> * You will be able to
subscribe to notifications for a specific issue<br>
>> labels. We have a proof of
concept notification system using github actions<br>
>> that will be used for this.<br>
>><br>
>> * Emails will be sent to
llvm-bugs when issues are opened or closed.<br>
>><br>
>> * We have the initial list of
labels: <a
href="https://github.com/llvm/llvm-project/labels"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://github.com/llvm/llvm-project/labels</a><br>
>><br>
>> == Remaining issue:<br>
>><br>
>> * There is one remaining
issue that I don't feel we have consensus on,<br>
>> and that is what to do with
bugs in the existing bugzilla. Here are some
options<br>
>> that we have discussed:<br>
>><br>
>> 1. Switch to GitHub issues
for new bugs only. Bugs filed in bugzilla that
are<br>
>> still active will be updated
there until they are closed. This means that over<br>
>> time the number of active
bugs in bugzilla will slowly decrease as bugs are
closed<br>
>> out. Then at some point in
the future, all of the bugs from bugzilla will be
archived<br>
>> into their own GitHub
repository that is separate from the llvm-project
repo.<br>
>><br>
>> 2. Same as 1, but also create
a migration script that would allow anyone to<br>
>> manually migrate an active
bug from bugzilla to a GitHub issue in the
llvm-project<br>
>> repo. The intention with
this script is that it would be used to migrate
high-traffic<br>
>> or important bugs from
bugzilla to GitHub to help increase the visibility
of the bug.<br>
>> This would not be used for
mass migration of all the bugs.<br>
>><br>
>> 3. Do a mass bug migration
from bugzilla to GitHub and enable GitHub issues
at the same time.<br>
>> Closed or inactive bugs would
be archived into their own GitHub repository, and
active bugs<br>
>> would be migrated to the
llvm-project repo.<br>
>><br>
>><br>
>> 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 <a href="http://llvm.org/PRxxxxx"
rel="noreferrer" target="_blank"
moz-do-not-send="true">llvm.org/PRxxxxx</a> <<a
href="http://llvm.org/PRxxxxx" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://llvm.org/PRxxxxx</a>>,
and if we can preserve all the issue numbers this
would ease the transition pain substantially.<br>
>> <br>
>><br>
>> The key difference between
proposal 1,2 and 3, is when bugs will be archived
from bugzilla<br>
>> to GitHub. Delaying the
archiving of bugs (proposals 1 and 2) means that
we can migrate<br>
>> to GitHub issues sooner
(within 1-2 weeks), whereas trying to archive bugs
during the<br>
>> transition (proposal 3) will
delay the transition for a while (likely several
months)<br>
>> while we evaluate the various
solutions for moving bugs from bugzilla to GitHub.<br>
>><br>
>><br>
>> The original proposal was to
do 1 or 2, however there were some concerns raised
on the list<br>
>> that having 2 different
places to search for bugs for some period of time
would<br>
>> be very inconvenient. So, I
would like to restart this discussion and
hopefully we can<br>
>> come to some kind of
conclusion about the best way forward.<br>
>><br>
>> Thanks,<br>
>> Tom<br>
>><br>
>>
_______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>><br>
>> <a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>>
_______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>><br>
>> <a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>><br>
>>
_______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<mailto:<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>><br>
>> <a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>
_______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
<mailto:<a href="mailto:cfe-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>><br>
> <a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
> <br>
> <br>
> <br>
>
_______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
> <a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>