Mailman 3 December 2016 - core-workflow

GitHub migration update for 2016-12-19
by Brett Cannon 22 Dec '16

22 Dec '16

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 https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9. 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.

5 9

Windows of opportunity to do the GitHub migration
by Brett Cannon 17 Dec '16

17 Dec '16

[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 slip). 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/issue589 and 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 ( https://www.python.org/dev/peps/pep-0512/#cpython-repo). 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 long. ;)

2 3

New core-workflow issue tracker
by Brett Cannon 09 Dec '16

09 Dec '16

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.

3 4

Fate of SVN externals
by Antoine Pitrou 07 Dec '16

07 Dec '16

Hello, 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 http://svn.python.org/projects/external/ 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? Regards Antoine.

2 2

GitHub migration update for 2016-12-03
by Brett Cannon 05 Dec '16

05 Dec '16

- 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.

3 3

Choosing a code coverage reporter
by Brett Cannon 03 Dec '16

03 Dec '16

I have both Codecov and Coveralls up and running. If you have an opinion/preference, please vote at https://github.com/brettcannon/cpython-ci-test/issues/27 using the reactions on the appropriate comment (.e.g +1/-1 reaction for Codecov and/or Coveralls). Links to the code coverage results are in the issue. If people want to see how they interact with PRs, feel free to look at https://github.com/brettcannon/cpython-ci-test/pull/32 (once the CI run is finished).

2 3