Mailman 3 May 2017 - python-committers

I have blocked Wes Turner from the Python org on GitHub
by Brett Cannon June 2, 2017

June 2, 2017

In the (long) discussion of https://github.com/python/core-workflow/issues/6, Wes Turner began to do his usual posting of lists. People pointed out he was stepping out of line by being somewhat off-topic and seemingly lecturing folks. He posted some of his lists again and then I warned him that if he did it again I would block him for a CoC violation since he did not want to respect anyone's time by taking the time to edit what amount to dumping his personal notes on GitHub. (This is a long-standing issue, BTW, with Wes where he has been warned in other settings like distutils-sig about his posting behaviour.) Unfortunately he did it again for https://github.com/python/core-workflow/issues/66. Since GitHub only has organization-level blocks I have blocked him at that level (I've also already received some +1s from core devs while writing this email for my move, so I know others who have interacted with him also support this decision).

11 16

Travis skipping the test build
by Brett Cannon May 31, 2017

May 31, 2017

At the moment Travis is not running the test build (it's actually not even listing it as a build). You can look at master, 3.6, or 3.5 to see that only the docs and coverage builds are being run: https://travis-ci.org/python/cpython/branches . I don't know why this is as it was fine yesterday and then stopped working today. The last change was from Antoine but its own Travis run ran fine so I don't think that caused the problem: https://github.com/python/cpython/commits/master/.travis.yml . If anyone can figure out if this is somehow our fault that would be great (I can't see how it is). But the key thing is to be aware that Travis being green just means the docs built fine. So until this is resolved, try to remember to check if the coverage test run passes if you want Travis to check your non-doc changes.

2 2

Appveyor tests failing for CPython?
by Alex Gaynor May 29, 2017

May 29, 2017

Hi all, It looks like appveyor tests are currently failing on all builds (something about UNC paths + imports). Was appveyor enabled recently, or did the test regress? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

2 3

Added a "sprint" label to GitHub
by Brett Cannon May 28, 2017

May 28, 2017

After reading a tweet from Nick ( https://twitter.com/ncoghlan_dev/status/868343982698266624) I realized it probably would have been good to label PRs from sprinters at PyCon US so they could get priority while the contributor was in the room or at least try to address them quickly after the sprint. So I added a "sprint" label that can be added to any PRs created during a sprint.

2 1

Labels on GitHub now have classification prefixes
by Brett Cannon May 27, 2017

May 27, 2017

https://github.com/python/cpython/labels now have prefixes for all labels to make it easier to find the relevant labels for some kind of classification. For instance, all the labels for the type of PR -- e.g. bugfix, enhancement, etc. -- now all have a "type-" prefix so you know what your options are (adding more labels is also always an option). This also makes it easier to tell which PRs are lacking possible labels for each classification (e.g. which PRs don't have a "type" label yet).

1 0

Guide to pushing to submitters' repo?
by Antoine Pitrou May 25, 2017

May 25, 2017

Hi, We now have a functionality to allow core developers to push to PR repositories, but I can't find out how to make it work. For example I have: $ git remote -v gescheit git://github.com/gescheit/cpython.git (fetch) gescheit git://github.com/gescheit/cpython.git (push) origin https://github.com/python/cpython (fetch) origin https://github.com/python/cpython (push) pitrou git@github.com:pitrou/cpython.git (fetch) pitrou git@github.com:pitrou/cpython.git (push) Then I try: $ git push fatal: remote error: You can't push to git://github.com/gescheit/cpython.git Use https://github.com/gescheit/cpython.git So I try with the HTTPS URL instead: $ git remote set-url gescheit https://github.com/gescheit/cpython.git $ git push Username for 'https://github.com': ^C Did someone manage to make this work? Can they post the entire instructions they used? (including local branch setup) (Context: trying to edit https://github.com/python/cpython/pull/1785) Thank you Antoine.

5 8

Proposing Carol Willing to become a core developer
by Brett Cannon May 25, 2017

May 25, 2017

While at the PyCon US sprints the idea came up of offering Carol Willing developer privileges. Everyone at the table -- about 6 of us -- liked the idea and Carol also said she would happy to become a core dev, so I'm officially putting her forward for consideration. For those of you who don't know Carol, she basically knows our developer workflow better than most of us. :) ; she's very active on the devguide and core-mentorship. Carol has also attended the PyCon US language summit two years in a row as a representative for the Jupyter project. She is actually so good with new people that she managed to get my wife to make her first open source contribution (something I never managed to do). As usual, if you support/object to this idea, please say so. :)

21 25

Feedback on the new CPython workflow
by Victor Stinner May 18, 2017

May 18, 2017

Hi, I wanted to wait a little bit before giving back my feedback on the new workflow. I just attend Brett Canon's talk at the Language Summit. So here are my misc notes on the new workflow. * Is there anyone already working on the workflow who would like to get a grant (money!) from the PSF? * If I want to share a change to review but it must not be merged, would it be possible to prevent merge by mistake? Maybe add [WIP] to the title and modify our bot to mark the "build" as failed? For example, I wrote a patch which depends on a different patch but I didn't want to create a patch serie since it didn't make sense. * AppVeyor is now quite stable. I fixed a few unstable tests. I suggest to mark this CI as mandatory. The CI is as fast or even faster than Travis CI! But it seems like it accepts less jobs in parallel :-/ It might be an issue if we get a huge number of PR in a short period (ex: during an event like Pycon US). * Currently, cherry-picker works a single step. It would be nice to have at least 2 steps: first cherry-pick locally, then allow to review the patch locally and run some specific tests, and then send the PR. By the way, instead of only using the sha1 to build the branch name, it would be nice to add also the bpo number. * I suggest to track backports at bpo since an issue tracks all PR and it seems like most core developers want to put most informations in the issue rather than GitHub. * Find a way to keep the Code coverage job, but don't mark the PR as failed if the coverage is considered as "failed"? It's strange to see a long list of PR with the red sign (failed) whereas Travis and AppVeyor passed. I have a lot of other minor remarks, but I prefer to stop here ;-) Victor

4 5

Sphinx 1.6.1 is causing Travis to fail
by Brett Cannon May 16, 2017

May 16, 2017

Looks like they added some new warnings that are causing the docs build to fail (e.g. https://travis-ci.org/python/cpython/jobs/232903226 and https://travis-ci.org/python/cpython/jobs/232897796). I will see if I have time to fix this before I leave for PyCon US today, but there's no guarantee. If someone has time to fix this then I've opened https://bugs.python.org/issue30380 to track the problem and give my take on a solution.

2 3

The "cherry-pick to *" labels on GitHub are gone
by Brett Cannon May 13, 2017

May 13, 2017

People didn't always remember to add the labels and they were redundant with people specifying the branch in the title along with the PR that the cherry-pick originated from (e.g. "[3.6] Something changed (GH-12345)").

1 1