As a result, all closed issues essentially got sortedĬhronologically before the real open ones. Looks like it was implemented like "re-open issue, transfer and closeĪgain"). Migration sets the last modification date of the closed issues (it Notifications are still sent in some cases ![]() We also have to rely on GitHub hereĪs we cannot do it via rate-limited API callsĭuring the final checks two issues were revealed: This step is crucial and one-way, once started weĬannot undo the steps we'd made. ![]() Let me provide more information about what is going on now andĪs a reminder, previously we imported all issues in the archive repoĪnd essentially the very last step remained: migration to the live ( ) might already have noticed that we're stuckĪgain. Some of you who are checking the migration notes > Something isn't clear to me here and I'm concerned about this setup: how are we gonna go from the "archived number" to the "real" monorepo issues? On Tue, at 10:23 AM Anton Korobeynikov wrote: Updated, so all references to #12345 will be rewritten to the new Will redirect to the final monorepo issue regardless whether it wasįrom bugzilla or the "new" github-only variant (it redirects toĪrchive for "low" NNNNN numbers and to monorepo for everything else).Īlso, during the transfer all github-internal issue links will be Will redirect to llvm/llvm-project/issues/45678. Number is lost, however, it will not: llvm/llvm-bugzilla-archive/12345 assume that the original bugzilla issue 12345 will be transferred However, GitHub will maintain the mapping for us and enable theĮ.g. Will be renumbered and there is no way to control this (sick!). Sorry for not being 100% clear as this is a bit tricky :)Īfter the transfer from archive repo to the llvm-project, the issues > I hope we don't lose this mapping, that seems quite critical to me. > I don't even understand the need for the archive repository right now: why can't we just redirect /PR to the monorepo issue? LLVM Developers mailing Something isn't clear to me here and I'm concerned about this setup: how are we gonna go from the "archived number" to the "real" monorepo issues? We are waiting for them to resolve itĪnd expect the final migration to happen within the next 48 hours. GitHub has a way to disable notifications, however, they found some Some active community members the volume of notifications would be To any issue in the past would receive multiple notifications. We certainly do not want that everyone who contributed Not trigger any notifications, the transfer will trigger all kinds of Also, while the import of issues to the empty repo does This step is in some sense final - we cannot undo it since we'll startĭoing this. on the existing repo, however, the URLs relative to theĪrchive repo will allow us to keep the original bugzilla issue numbersĪnd also, github will rewrite all references inside the comments for The issue numbers only on the empty repo and we cannot lose the Of compromise we have to accept as we can ensure the preservation of Issues in the single repo (albeit with different numbers, this is kind ![]() The last remaining step is the transfer of the issues from bugzillaĪrchive to the main llvm-project repo. Will forward to the read-only bugzilla instance It will redirect toīugzilla archive for all PRs with ids <= 52601 and to the main ![]() Will be the basis of our stable numbering of the issue id's. All issue numbers are preserved wrt this repo. All bugzilla content is imported to the bugzilla archive GitHub We have to wait until the outage ended, have to restart the import andĪlso GitHub support engineers that watched our migration were moved to That happened over the weekend and our schedule was delayed a bit as I would like to give you the status update of our bugzilla migration.įirst of all, unfortunately it was affected by the major GitHub outage
0 Comments
Leave a Reply. |