<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><br>This 5000 request per hour limit, is that per repo or per access token? Could we potentially make a pool access token from multiple github accounts to sidestep the issue? Say 20 tokens to do the migration in 1 hour?<br><br>--Jeff Miller<br>-------- Original Message --------<br>On Dec 1, 2021, 11:36 PM, Anton Korobeynikov via cfe-dev < cfe-dev@lists.llvm.org> wrote:<blockquote class="protonmail_quote"><br><p dir="ltr">Dear All,</p>
<p dir="ltr">Some of you who are checking the migration notes<br>
(<a href="https://bit.ly/3HVjr7a">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.</p>
<p dir="ltr">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</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">For now I'm testing the script for 3. and waiting for any news from GitHub.</p>
<p dir="ltr">I will keep you updated.</p>
<p dir="ltr">--<br>
With best regards, Anton Korobeynikov<br>
On behalf of LLVM Foundation<br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</p>
</div>