-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration and risk management plans #13
Comments
This is now done. |
Is there anything to be done for this or can we check it off? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue describes the migration plan, testing strategy, execution plan, and risk management plan. This list of steps is not final, new steps might be added, the time estimates should be more accurate, and each step should be assigned to someone. This plan overrides PEP-588, and might eventually be turned into a PEP. For the time being is kept here for convenience.
This document uses the following terms:
Migration plan
These are the steps required to migrate issues from bpo to GitHub:
~25h~12h *)cpython
repocpython
repo (~4-7d~20h **)cpython
repo*
Importing 500 issues (without attachments) on a Friday morning (Europe)/Thursday night (US) took 13m. We currently have almost 60k issues, so it should take around 25h. Earlier imports took about half of this time though, so it might depend on the server load.Further testing showed that it takes about 12h.** The transfer has been optimized, and it now takes about 20h.
Testing strategy
Each step of the previous list should be tested (if possible):
3.
this has also been tested and should be tested with a full import before the actual migration.python/cpython
.GitHub Actions (e.g. updating issue references) can be tested on separate repos, and possibly added to the source tree before the migration starts.we currently don't have any additional actions.Execution plan
If all goes well, these are the actions that we will take:
python-dev
/python-commiters
, posts on Discourse, blog posts and other social media, and a banner on bpo.python/cpython
-> bpo webhook (@ezio-melotti)Start a backup import ~4h in (@ezio-melotti)github
field of all issues on bpo (@ezio-melotti)bpo-*
autolinking onpython/cpython
(@ezio-melotti)cpython
repo, allowing users to create new issues.There are also a number of related changes that should be done:
.github/actions/
onpython/cpython
python/cpython
python/core-workflow#432python/cpython
python/core-workflow#4370
s in URL python/peps#2420 and Support redirects from non-padded PEP numbers python/peps#2421)After the migration, and once we have the bpo->GH mapping, we could:
bpo-*
refs with actualGH-*
refs (this enables the mouse-over popup)Duplicate of GH-*
(this enables duplicates tracking)These changes affect the "Last update" datetime, so we could do them lazily through a GitHub action whenever someone edits an existing issue.
Risk management plan
This section discusses the failures we might encounter during each step of the migration and suggest ways to prevent them and deal with them. None of these things are expected to happen, but we should have a plan B just in case.
Once we inform the users:
When we make bpo read-only:
Exporting issues from bpo:
Import issues in the ECI:
Possibly partially lock the
cpython
repo:Transfer issues to the
cpython
repo:Possibly setup and run post-migration actions
Unlock the
cpython
repo and test everythingInform the users that the migration happened
The text was updated successfully, but these errors were encountered: