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 :-)
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.
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.
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!
nad(a)python.org -- 
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?
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
I'm using https://github.com/python/core-workflow/issues/91 to track the
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
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.
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
What do you think?