Mailman 3 June 2017 - python-committers

Fun fact, The Knights Who Say "Ni" (bot) complained about CLA on Modules/expat/
by Victor Stinner 22 Jun '17

22 Jun '17

Hi, Fun fact: I cherry-picked a change from libexpat into Modules/expat (VS2008 fix for stdint.h), and I kept the author. Then The Knights Who Say "Ni" (bot) complained that Sebastian Pipping <sebastian(a)pipping.org> didn't sign the CLA :-) https://github.com/python/cpython/pull/2312#issuecomment-310091014 I fixed the issue by replacing the author with me :-/ Well, I already took the ownership of most lines of Modules/expat/ since I upgraded libexpat from 2.1.1 to 2.2.0, and today to 2.2.1. So I don't think that it's a new issue. I just wanted to share this story with you: the bot works as expected :-) Note: libexpat is distributed under the MIT license. Victor

2 1

Bedevere now automatically removes "needs backport to *" labels
by Brett Cannon 21 Jun '17

21 Jun '17

When you create a backport PR, if the title is formatted as, e.g. "[3.6] stuff that changed (GH-1234)", then Bedevere will remove the "needs backport to 3.6" label on the GH-1234 PR and leave a comment linking to the backport PR that triggered the label removal.

5 6

[RELEASE] Python 3.6.2rc1 is now available for testing
by Ned Deily 17 Jun '17

17 Jun '17

On behalf of the Python development community and the Python 3.6 release team, I would like to announce the availability of Python 3.6.2rc1. 3.6.2rc1 is the first release candidate for Python 3.6.2, the next maintenance release of Python 3.6. While 3.6.2rc1 is a preview release and, thus, not intended for production environments, we encourage you to explore it and provide feedback via the Python bug tracker (https://bugs.python.org). Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.2rc1 here: https://www.python.org/downloads/release/python-362rc1/ and its change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-2-release-ca… 3.6.2 is planned for final release on 2017-06-30 with the next maintenance release expected to follow in about 3 months. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

1 0

Promote Julien Palards as Committers on docsbuild-scripts
by Victor Stinner 15 Jun '17

15 Jun '17

Hi, Would it be possible to give the commit bit to Julien Palards on the following project (only on this project)? https://github.com/python/docsbuild-scripts/pulls His GitHub account is "JulienPalard": https://github.com/JulienPalard Thanks to the migration to GitHub, we are now able to give access to someone to a single repository, no? He wrote the documentation translation which has been accepted by Guido in May: https://www.python.org/dev/peps/pep-0545/ Julien needs to make minor changes to the documentation build system to support translations, see his pull request: https://github.com/python/docsbuild-scripts/pull/11 The Git repository of docsbuild-scripts has 41 commits and 7 of them (17%) are already written by Julien :-) Victor

4 8

IMPORTANT: Python 3.6.2 Maintenance Release Release Candidate in 3+ days (Monday 2017-06-12 12:00 UTC)
by Ned Deily 15 Jun '17

15 Jun '17

We are approaching the end of the second calendar quarter of 2017 and, according to PEP 494, it's time to start producing the second maintenance release for the 3.6 series. The schedule calls for the release candidate to be produced on Monday 2017-06-12 UTC. As was the case with previous 3.6.x releases, the plan is for the release candidate to be the same as the final release, that is, no additional changes go in after the release candidate except for any showstopper critical problems that might be discovered with rc1. So please plan to get any security fixes, bug fixes, and documentation changes you think should be in 3.6.2 merged in ASAP. The 3.6.2 final is planned for two weeks following rc1, that is, on 2017-06-26. The next 3.6 maintenance release (3.6.3) is planned to follow about 3 months later, so most likely in 2017-09. A reminder that the 3.6 branch will remain open for checkins throughout the 3.6.2rc and final cycle. Once 3.6.2rc1 is tagged, new commits to the 3.6 branch will release with 3.6.3. As always, if you find any problem in 3.6.2rc1 that you may believe should be corrected in 3.6.2, please ensure the problem is documented in a new or existing open issue on bugs.python.org, ensure that the Priority field of the issue is set to "release blocker", and that "Python 3.6" is included in the selected Versions. Comments or tags on github Pull Requests are NOT sufficient! Thanks again for all of your efforts in bringing 3.6 into the world and for helping now to make it even better! https://www.python.org/dev/peps/pep-0494/ http://cpython-devguide.readthedocs.io -- Ned Deily nad(a)python.org -- []

2 3

Sporadic failures in test_multiprocessing_main_handling?
by Antoine Pitrou 13 Jun '17

13 Jun '17

Hello all, Are we aware of sporadic failures in test_multiprocessing_main_handling? I got a hang here and I'm wondering if it's due to my changes: https://travis-ci.org/python/cpython/jobs/242108490#L2211 Thanks & Regards Antoine.

2 3

Windows License for a core dev
by Mariatta Wijaya 08 Jun '17

08 Jun '17

Hi, During the language summit I overheard that as a core developer, I can get free Windows License. Is this true? If so, how can I get one, and will it work with VirtualBox on mac? Thanks. Mariatta Wijaya

3 2

macOS builds conditionally turned on for Travis
by Brett Cannon 03 Jun '17

03 Jun '17

I have turned on macOS builds on Travis for all active branches, but for now the builds are allowed to fail. The latter detail is so that we can be sure that the tests are stable on Travis before blocking on it as well as see if the added build time is acceptable for blocking a PR on. If the tests end up being stable for at least a week and the added time is deemed acceptable then we can make the macOS builds required for Travis to be considered passing. I'm using https://github.com/python/core-workflow/issues/91 to track the requirements discussion.

1 0

I have blocked Wes Turner from the Python org on GitHub
by Brett Cannon 02 Jun '17

02 Jun '17

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

Please stop fixing easy issues right now! Leave them as exercices to newcomes
by Victor Stinner 02 Jun '17

02 Jun '17

Hi, I discussed with Mariatta and Carol at Pycon US about new contributors and the difficulty to find "easy issues" to start contributing to CPython. The thing is that easy issues usually are fixed in less than 24 hours which doesn't give the opportunity to newcomers to fix them. *Many* people ask me regulary "how to find easy Python issues", and the last 3 years, I always failed to find such issues... Many "easy issues" are older than 3 years old, have more than 20 comments and no compromise has been found how to fix the "easy" issue... I propose a new policy for core developers: stop fixing really easy issues! I suggest to follow Brett Cannon's example. Instead of fixing importlib bugs, Brett told me that he started to describe the bug and explain how to fix it. According to his own experience, it works well and is very valuable! The plan is to recruit new contributors and mentor them to grow our team. More contributors = more people to review changes = more diversity = less bugs = etc. (long win-win list ;-)) I started with 4 issues on reference leaks found by new Zachary's "Refleak" Gentoo and Windows buildbots. I used a script that I wrote to identify one test leaking references, but I didn't write the fix. Usually, writing the fix is the simplest task: the boring and complex task is more to isolate the leaking test method. Hum, the next step is to explain how to fix such issue, I may do that on the core menthorship mailing list. http://bugs.python.org/issue30547 http://bugs.python.org/issue30546 http://bugs.python.org/issue30542 http://bugs.python.org/issue30536 I added [EASY] in the issue title to advertise these issues and used the "easy (C)" keyword. Since the proposal rule asking core dev is new, I also write a comment to explain my plan ;-) More generally, I now suggest to spend more time on mentoring newcomers and review changes instead of writing new changes. This idea is not mine, it's just a very good advice that Mariatta gave me ;-) Since I know that it's a very different job and can be seen as less interesting, it's not mandatory at all! It's just an advice if you want to try "something new" ;-) I will also try to spend more time next weeks on our core menthorship mailing list. What do you think? Victor

3 3