<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>This thought had occurred to me as well. Using a separate repo
for bug tracking seems reasonable as an intermediate step. Unless
there's a complexity here I'm missing, I'd probably vote for that
in favor of going all the way back to bugzilla.</p>
<p>Philip</p>
<p>p.s. Anton, thank you for the update and all the work that has
gone into this. <br>
</p>
<div class="moz-cite-prefix">On 12/2/21 12:18 AM, MyDeveloper Day
via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD7AeN5=KzTf3aRDw9KokUpo26c3Cv36Oh9FqW25ZwTuY=-sQg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">What bad stuff happens if you just open up <a
href="https://github.com/llvm/llvm-bugzilla-archive/issues"
moz-do-not-send="true">https://github.com/llvm/llvm-bugzilla-archive/issues</a>
(even if you then make another historical archive later) to use
as the bug tracker until you and github have ironed out all the
migration from one project to another project issues? rather
than going all the way back to bugzillia which is then going to
impose some other multi day migration at a later point.
<div><br>
</div>
<div>In my mind I've already divorced from bugzilla, I'm ready
to move on with my life with github!<br>
<div>
<div><br>
</div>
<div>MyDeveloperDay</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Dec 2, 2021 at 7:36 AM
Anton Korobeynikov 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>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear
All,<br>
<br>
Some of you who are checking the migration notes<br>
(<a href="https://bit.ly/3HVjr7a" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://bit.ly/3HVjr7a</a>)
might already have noticed that we're stuck<br>
again. Let me provide more information about what is going on
now and<br>
what the plans are.<br>
<br>
As a reminder, previously we imported all issues in the
archive repo<br>
and essentially the very last step remained: migration to the
live<br>
llvm-project repo. This step is crucial and one-way, once
started we<br>
cannot undo the steps we'd made. We also have to rely on
GitHub here<br>
as we cannot do it via rate-limited API calls<br>
<br>
During the final checks two issues were revealed:<br>
- Notifications are still sent in some cases<br>
- Migration sets the last modification date of the closed
issues (it<br>
looks like it was implemented like "re-open issue, transfer
and close<br>
again"). As a result, all closed issues essentially got sorted<br>
chronologically before the real open ones.<br>
<br>
These issues were fixed at GitHub side and we proceeded with<br>
re-checking everything. It turned out that another issue
appeared: the<br>
labels were silently lost and the migrated issues were
completely<br>
labelless, despite being annotated by 140+ labels we had
originally.<br>
For now this is a show-stopper issue. The issue was reported
and<br>
acknowledged by GitHub, however, not ETA was provided.<br>
<br>
Our current options are:<br>
1. Abandon the migration<br>
2. Wait until the issue is resolved on GitHub side<br>
3. Try to find alternative solutions to workaround GitHub
issue<br>
<br>
2. is essentially not an option. I am proposing to abandon the<br>
migration and unlock the bugzilla if the solution will not be
found by<br>
the end of this week.<br>
<br>
The only alternative I'm seeing is to apply the labels
post-migration.<br>
There are important downsides:<br>
- This has to be done via GitHub API and we're rate limited
to ~5000<br>
requests per hour, so this means that the labelling will take
~20<br>
hours. I was told that there is no way for us to have the API
rate<br>
limit increased.<br>
- This might trigger notifications. My quick check via web
ui does<br>
not, but I cannot be 100% with anything here<br>
- (the most important) This will screw the "last modified"
timestamp<br>
as label setting is an event that is recorded in the issue.
There is<br>
no way to set some "old" timestamp, it is assigned by GitHub<br>
automatically.<br>
<br>
For now I'm testing the script for 3. and waiting for any
news from GitHub.<br>
<br>
I will keep you updated.<br>
<br>
-- <br>
With best regards, Anton Korobeynikov<br>
On behalf of LLVM Foundation<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><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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>