Mailman 3 May 2017 - python-committers

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