The biggest update is I have updated the code for hg.python.org/lookup.
Once the hg repo is read-only I will generate a final JSON file containing
every commit and then have the new code and data uploaded. If you want to
look at the modified code and double-check my work then please look at
I have also added a TODO to make sure the docs will build from git (kind of
an important thing :) ). I'll reach out to the appropriate people to see
what that will take.
[sending this independently to python-dev and core-workflow]
I have promised Ned that we will not migrate before 3.6.0 is released and
not for a week following in case an emergency 3.6.1 is necessary. I also
promised Larry we wouldn't migrate the week before 3.5.3 is released. That
means the windows for migrating are 2016-12-30 to 2017-01-09, and then any
time after 2016-01-16 (this of course assumes all release schedules don't
I'm now on vacation until January 3 so I will have time to work on the
migration some more. I will port hg.python.org/lookup to work with git, hg,
and svn probably this week or next. That leaves the only true blockers as
http://psf.upfronthosting.co.za/roundup/meta/issue590 (webhook for PR to
issue and notifying an issue when a commit has occurred, respectively; we
already have a GitHub PR field on b.p.o for manual entry). Once those
changes to bugs.python.org land and have been tested live against the
GitHub mirror, we can do the migration (which will most likely take a day
or two). All other issues either require the repo to have already been
migrated and working or can wait post-migration (
So if the above wasn't clear, if you want to help then please help with the
b.p.o issues as those are the remaining blockers I can't deal with on my
own. And I actually have GitHub-themed gifts I bought myself sitting under
my Xmas tree that I won't open until we migrate, so let's not take too
I have created https://github.com/python/core-workflow to track ideas and
plans related to this mailing list. Figured that while this list is nice
for discussion an issue tracker was needed to track is actually planned.
Windows builds rely on hand-maintained copies (sometimes patched) of
external libraries. Those copies are currently maintained in SVN
(yes, you read this correctly). The URL is
Not only does this mandate an additional dependency to run a Windows
build (I don't think we use SVN anywhere else), but it actually makes
them unpleasantly slower, because SVN is crappy at making checkouts.
Is it planned to move that repo to git?
- Started the conversation with Zach Ware about updating the buildbots
(doesn't sound too troublesome)
- Maciej and Ezio got a GitHub PR field added to bugs.python.org
- Next step is to review
http://psf.upfronthosting.co.za/roundup/meta/issue589 so that PRs
automatically populate the field on b.p.o
- Once we make the connection from PR to issue then
http://psf.upfronthosting.co.za/roundup/meta/issue590 can be reviewed
so that commits leave a comment on b.p.o
- I got the code for hg.python.org/hglookup
- Asking if there's any reason I can't post it publicly
- Need to figure out the best way to extract all commit IDs from a
- Need to update the code to use the commit IDs (both 12 and 40
character lengths) for linking to hg commits
- Need to update the code to accept 10 or longer hashes from git
(default used to be 7, but git 2.11 now calculates the shortest,
unamibiguous hash and CPython is big enough to need 10 characters)
- Everything else either requires we have moved over to GitHub or isn't
- Chose Codecov for our code coverage provider!
I think that's everything that's blocking migration. If people want to help
then please have a look at
see if anything was missed for the migration and/or help Ezio and Maciej
with the b.p.o changes.
As soon as we migrate we will want to solve the Misc/NEWS problem as that
will be the biggest pain point/regression compared to the hg workflow. You
can read the PEP for the chosen workflow if people want to start thinking
about a solution.
After fixing Misc/NEWS the next pain point will be coming up with the best
way to handle cherry picking (initially we will use labels to keep track of
PRs that need backporting, but obviously automating the creation of the
cherry picks as PRs would be great and this will require solving the
>From there things will simply be beneficial, e.g. automating Misc/ACKS.