GitHub migration update for 2016-12-03
- 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 Mercurial repoistory - 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 a blocker - 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 http://cpython-devguide.readthedocs.io/en/github/ and 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 Misc/NEWS problem).
From there things will simply be beneficial, e.g. automating Misc/ACKS.
On Sun, 04 Dec 2016 00:40:49 +0000 Brett Cannon <brett@snarky.ca> wrote:
- I got the code for hg.python.org/hglookup - Asking if there's any reason I can't post it publicly
None than I can think of.
- Need to figure out the best way to extract all commit IDs from a Mercurial repoistory
Probably iterate over all entries in the revlog and inspect the "extra" field as is done in hglookup? That way you can build a static mapping of SVN rev -> hg changeset ID, and save it e.g. to a file.
- 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)
I'm not sure I understand those two points, but that probably doesn't matter. Regards Antoine.
On Mon, 5 Dec 2016 at 04:14 Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 04 Dec 2016 00:40:49 +0000 Brett Cannon <brett@snarky.ca> wrote:
- I got the code for hg.python.org/hglookup - Asking if there's any reason I can't post it publicly
None than I can think of.
- Need to figure out the best way to extract all commit IDs from a Mercurial repository
Probably iterate over all entries in the revlog and inspect the "extra" field as is done in hglookup? That way you can build a static mapping of SVN rev -> hg changeset ID, and save it e.g. to a file.
- 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)
I'm not sure I understand those two points, but that probably doesn't matter.
hg.python.org/lookup says any hexadecimal number that is 12 or 40 digits is an hg commit ID, but git uses 10 or 40 digits for our repo for a commit hash. The 10 digit and 12 digit lengths don't clash but the 40 digit one does.
On Mon, 05 Dec 2016 23:45:52 +0000 Brett Cannon <brett@python.org> wrote:
- 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)
I'm not sure I understand those two points, but that probably doesn't matter.
hg.python.org/lookup says any hexadecimal number that is 12 or 40 digits is an hg commit ID, but git uses 10 or 40 digits for our repo for a commit hash. The 10 digit and 12 digit lengths don't clash but the 40 digit one does.
I see. Thanks for the clarification. Regards Antoine.
participants (3)
-
Antoine Pitrou -
Brett Cannon -
Brett Cannon