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

Created a Bedevere bot account on GitHub
by Brett Cannon May 9, 2017

May 9, 2017

Just so no one thinks anything fishy is going on, I wanted to let the team know that I created https://github.com/bedevere-bot and now have Bedevere using this account instead of piggybacking off of https://github.com/the-knights-who-say-ni. I figured they should be separate for security reasons as the Ni bot accesses many more accounts than Bedevere. Plus I wanted an appropriate profile photo for Bedevere. :) P.S. In case anyone cares, core-workflow-owner@ is set up as the email address for both accounts, so the accounts can be recovered by others if need be.

1 0

Proposal for procedures regarding CoC actions
by Raymond Hettinger May 5, 2017

May 5, 2017

I would like to make a procedural proposal based on the ideas emerging from the other python-committers discussion regarding the two month suspension of Github project access for a developer who was posting non-productively. It seems that there is general agreement to differentiate commonplace list moderation actions from CoC actions which are more of a nuclear option to be reserved for egregious cases of harassment and abuse. Also, there is general agreement not to concentrate that power in the hands of a single person and that we should have some principles and procedures in place. I propose that when someone thinks there is a problem serious enough to warrant a Code-of-Conduct action, that it get referred to a group of three people to make the decision. Two of those three people should be long-term, senior, and respected core devs who have good knowledge of the community (Brett Cannon, Nick Coghlan, Antoine Pitrou, et al). The third person should be someone who is also well-respected but more independent and who has more experience in sociology and community management issues (Alex Gaynor or Carol Willing come to mind). To prevent endless bickering and sharing of sensitive details, the group's decision should be considered settled business which can only be overridden either by an appeal to the PSF board or by the BDFL. When possible, the affected person should be contacted and given an opportunity to defend themselves. The decision shall be announced on python-committers with an overall rationale but without personal details. The group shall consider the needs of the community first and foremost, and secondarily shall prioritize being as respectful as possible to all parties, and thirdly shall do whatever they can to mitigate the harm to the violator. The actions shall be taken with an intent to protect the vibrancy of the Python community rather than with an intent to punish, humiliate, or discredit the affected person. When possible, some path to redemption or forgiveness shall be offered. Respectfully submitted, Raymond Hettinger

10 16

Github reviews are cannibalizing BPO
by Christian Heimes May 5, 2017

May 5, 2017

Hi all, since our move to Github I noticed a major increase in incoming patches. I like it. It clearly shows that it was a good decision. But I don't like the fact that Github reviews are cannibalizing issues on BPO. Before the migration decisions regarding a new feature or bug fix were made on the ticket system. For larger changes we used mailing lists or the PEP process. Rietveld, our previous code review tool, was just used to discuss code and implementation details. All important decisions still happened on BPO. We also used BPO to keep the experts or module maintainers in the loop. With Github I'm seeing a major paradigm shift. New contributors tend to use BPO as ticket number dispenser. Actual discussion seems to happen mostly on Github PRs. For me it makes it harder to follow discussion or to see discussions at all. I find Github notifications inferior to compared BPO's email notification -- mostly because Github spams me with notifications. For me it's not uncommon to have more than 1,000 open notifications waiting for my attention. This brings me to my questions 1) Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs? 2) How can we retain enough information on BPO to keep it useful as research database for past decisions? 3) How can we keep module maintainers and experts in the loop? For example I don't have the resources to read all Github PRs, but I still like to keep an eye on the ssl and hashlib module. Christian

16 34

Coverage build broken?
by Antoine Pitrou May 4, 2017

May 4, 2017

Hello, I'm getting the following error on the Travis-CI coverage job: (from https://travis-ci.org/python/cpython/jobs/228758363#L837 ) Collecting coverage Downloading coverage-4.3.4.tar.gz (361kB) Complete output from command python setup.py egg_info: running egg_info creating pip-egg-info/coverage.egg-info writing pip-egg-info/coverage.egg-info/PKG-INFO writing dependency_links to pip-egg-info/coverage.egg-info/dependency_links.txt writing entry points to pip-egg-info/coverage.egg-info/entry_points.txt writing top-level names to pip-egg-info/coverage.egg-info/top_level.txt writing manifest file 'pip-egg-info/coverage.egg-info/SOURCES.txt' warning: manifest_maker: standard file '-c' not found Traceback (most recent call last): File "<string>", line 1, in <module> File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 204, in <module> main() File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 194, in main setup(**setup_args) File "/home/travis/build/python/cpython/Lib/distutils/core.py", line 148, in setup dist.run_commands() File "/home/travis/build/python/cpython/Lib/distutils/dist.py", line 955, in run_commands self.run_command(cmd) File "/home/travis/build/python/cpython/Lib/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py", line 279, in run self.find_sources() File "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py", line 306, in find_sources mm.run() File "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py", line 533, in run self.add_defaults() File "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py", line 562, in add_defaults sdist.add_defaults(self) File "/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line 228, in add_defaults self._add_defaults_ext() File "/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line 311, in _add_defaults_ext build_ext = self.get_finalized_command('build_ext') File "/home/travis/build/python/cpython/Lib/distutils/cmd.py", line 299, in get_finalized_command cmd_obj.ensure_finalized() File "/home/travis/build/python/cpython/Lib/distutils/cmd.py", line 107, in ensure_finalized self.finalize_options() File "/home/travis/build/python/cpython/Lib/distutils/command/build_ext.py", line 150, in finalize_options py_include = sysconfig.get_python_inc() File "/home/travis/build/python/cpython/Lib/distutils/sysconfig.py", line 100, in get_python_inc incdir = os.path.join(_sys_home, get_config_var('AST_H_DIR')) File "/home/travis/build/python/cpython/Lib/posixpath.py", line 92, in join genericpath._check_arg_types('join', a, *p) File "/home/travis/build/python/cpython/Lib/genericpath.py", line 149, in _check_arg_types (funcname, s.__class__.__name__)) from None TypeError: join() argument must be str or bytes, not 'NoneType' ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-ewtgqc2r/coverage/ Regards Antoine.

3 6

No Travis-CI on OS X?
by Antoine Pitrou May 3, 2017

May 3, 2017

Hi, Perhaps it would be possible to set up a Travis CI matrix entry for OS X, those builds are often quite slow but at least it could be part of the "allowed failures" suite. That would help detect platform issues at PR time rather than later :-) Regards Antoine.

5 5