Your comment already led us to consider and discuss a couple of different approaches and optimizations. We will perform a full test migrations beforehand to get a more accurate time estimation, and then consider the trade-offs involved and decide whether to add optimizations or not.
If I understand correctly the actual transfer eventually took them a couple of days, but it had a few false starts and issues. I’ve been talking with the project manager of the LLVM project and a few other people that performed similar migrations in the past, so that we could learn from their mistakes and avoid them.
I can ask him about the impact of the migration, even though their goals and priorities were somewhat different from ours.
The migration plan describes this in more details, but basically we are doing what you described:
- make bpo read-only and export all issues
- import all issues in an empty repo
- transfer the issues from the empty repo to
python/cpython
The first step takes about half an hour, the second step about a day, and the rest is taken by the third step.
The third step is already handled by GitHub from their backend and we don’t have control or opportunities to optimize it unless we decide to import a smaller subset first (e.g. only the open/active issues) and open up the issues to everyone while the older issues are still being transferred (this is possible, but will mess up the ID order). There is some room for optimization during the second step, but we have to see if it’s worth the extra time/complexity/risk.
Exporting old issues and marking them as read-only as they are exported is technically doable, but will require some work. The main issue with this is that if we can’t keep the “issues tab” disabled on GitHub during the transfer, people will see some old issues appearing on python/cpython and might start interacting with them and creating new ones before the migration is completed.
We are currently looking into possible solutions to fix this, so stay tuned 