Mailman 3 June 2017 - python-committers

Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California
by Lukasz Langa 22 Aug '17

22 Aug '17

Hello fellow committers! I'm organizing another core sprint this year to make Python 3.7 the best release possible. WHY: 1. Community. The sprints at the end of PyCon are great but they mostly get the same people in the room year after year. Many of the most active contributors never attend conferences. My goal with this sprint is to bring together many core devs who rarely if ever meet! 2. Focus. When we have sprints at the end of a conference, many of us are pretty tired and less productive than we could have been without the late dinners, endless hallway sessions, and so on. Some of the sprinters are preoccupied with tutoring newcomers. This sprint won't be after a major conference, and it's only for seasoned CPython core devs--so get to work! 3. Communication. There are tremendous benefits to getting everyone together in one big room. Conversations that drag on on python-dev can be solved quickly in person. Even contentious debates become faster, easier, and more civil. And meeting face-to-face helps us all feel more connected to our community. WHY THE BAY AREA: We have a large population of core contributors here. Also, I can arrange for Facebook to provide us a "war room" for the whole week, with full access to the campus during the sprints. That includes free food for breakfast, lunch, dinner, and snacks, compatible with almost any dietary restrictions. WHY EARLY SEPTEMBER: It's almost impossible to find a time that doesn't overlap with a PyCon. This week worked well last year so we're redoing it that way. Monday September 4 is Labor Day in the US, which may make it easier for employees of US companies to attend, as they'd only be taking off four days instead of five. HOW LONG: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can check into your hotel the day before the sprint (Sunday, Sep 3) and check out the day after (Saturday, Sep 9). HOW BIG: No fewer than 10, no more than 20. More than 20 people would be great but it'd be hard for me to organize a sprint that big. WHO PAYS: The venue, hotels, and food are provided by Facebook. I'm working on getting flight reimbursements. Last year they were provided by the Python Software Foundation. Anybody is free to waive their reimbursement. PLEASE REPLY: If you're interested in attending and have the commit bit on GitHub's python/cpython, fill out this Google Form: https://goo.gl/forms/MzrNtRe0NAmzvGwF2 <https://goo.gl/forms/MzrNtRe0NAmzvGwF2> DISCLAIMER: I'd like to be able to host everybody. However, if I receive more than 20 applications, this is not going to be possible. In this case, the following will happen: 1. I will look at your current level of involvement in CPython development. This includes metrics like commits / PRs, activity on the bug tracker and python-dev, special role (release manager, infrastructure dev, etc.). 2. I will look at your sprint plan and ability to participate in the entire sprint (per answers to the questions above). 3. I will gather all this data and leave the final decision to our Benevolent Dictator (who is also attending the sprint). This is one of those occasions where having a dictator is useful. DON'T WAIT: September is closer than you think! Please let me know as soon as possible so we can start setting up the event. I'm going to close the sign-up form on June 23rd. Organizational-ly yours, Ł Vice-Minister of Silly Sprints

7 9

Revert changes which break too many buildbots
by Victor Stinner 05 Jul '17

05 Jul '17

Hi, The CPython workflow was enhanced to get pre-commit CI checks. That's a huge win, thank you for that... But, sometimes, a change can still break many buildbots, bugs which weren't catched by pre-commit checks (Travis CI/Linux and AppVeyor/Windows). Buildbots cover much more different architectures and platforms. I spend a significant amount of time to maintain the sanity of our buildbots. Sometimes, it can take me up to 3 days on a week (of 5 working days). It's annoying to see new regressions while I'm trying hard to fix old ones :-( So I would like to set a new rule: if I'm unable to fix buildbots failures caused by a recent change quickly (say, in less than 2 hours), I propose to revert the change. It doesn't mean that the commit is bad and must not be merged ever. No. It would just mean that we need time to work on fixing the issue, and it shouldn't impact other pending changes, to keep a sane master branch. What do you think? Would you be ok with such rule? A recent example is Nick Coghlan's implementation of the PEP 538: basically, it broke all buildbots... except of Linux and Windows :-) And it will take a few more days to fix all failures. Well, we are working on fixing these issues, so I don't want to revert this change. It's just an example of a single change which broke many buildbots. The PEP 538 depends a lot on the platform, so I'm not surprised to see different failures per platforms ;-) By "buildbot failure", I mean a red buildbot failing because of compilation error or failed test suite. But I would prefer to ignore failures of the Refleak buildbots since these ones are not stable (even if there are less and less ref leaks in master, and these buildbots already catched recent regressions!). If the rule is approved, I plan to announce it on python-dev to be transparent. Victor

9 22

Travis now checks for whitespace issues in PRs
by Brett Cannon 28 Jun '17

28 Jun '17

I just pushed a change to master, 3.6, and 3.5 where Tools/scripts/patchcheck.py now has a --travis option which will run the whitespace fixers from `make patchcheck` but trigger a Travis build failure if any changes were necessary. This only runs on Linux so it is a PR blocker, but also so it isn't done more than once per PR. This was not backported to 2.7 because I honestly didn't want to do the work to fix the merge conflicts.

2 1

macOS Travis CI job became mandatory?
by Victor Stinner 27 Jun '17

27 Jun '17

Hi, I was waiting for the result of Travis CI: 3 jobs already completed, but the macOS job was still running. The macOS job is marked as "allowed failure". I cancelled the job, but then the Travis CI was marked as failed in the PR :-/ So I restarted the job. Is it normal to have to wait for the slow macOS job to be able to merge a PR? It's a recent change, no? Victor

3 9

link from github to bpo?
by Ethan Furman 25 Jun '17

25 Jun '17

My apologies if this has been discussed/answered before, but is there a link from the github side to the bpo side? For example, I'm looking at https://github.com/python/cpython/pull/2304 and it would be great if such a link existed to take me directly to the bpo issue. -- ~Ethan~

4 8

New workflow change: Welcome to blurb
by Larry Hastings 24 Jun '17

24 Jun '17

One minor but ongoing problem we've had in CPython core development has been the mess of updating Misc/NEWS. Day-to-day developers may have a conflict if they lose a push race, which means a little editing. You'll have a similar, if slightly worse, problem when cherry-picking a fix between versions. Worst of all used to be the manual merges necessary after cutting a release--this was the bane of a CPython release manager's existence. (Though the new git-based workflow may have obviated the worst of this.) The real problem is that we have one central file that everybody continually edits in a haphazard way. We aren't actually editing the same information, we aren't actually changing the same lines. But our revision control systems and diff algorithms don't understand the structure of Misc/NEWS and so they get confused. And for what? It's not like there's a tremendous benefit to having this central file everyone's fighting over. We've been talking about addressing this for years. Fixing this was one of the goals of the new workflow. And finally, as of right now, the future is here. Ladies and gentlemen, I present: blurb. https://github.com/python/core-workflow/tree/master/blurb blurb is an interactive command-line tool that helps you write Misc/NEWS entries. You simply run blurb from anywhere inside a CPython repo. blurb runs an editor for you with a template open. You fill in these three pieces of information: * the bugs.python.org or "bpo" issue number, * what "section" of Misc/NEWS this entry should go in (by uncommenting the correct line), and * the text of the Misc/NEWS entry, in ReST format. You save and exit and you're done. blurb even stages the Misc/NEWS entry in git for you! Behind the scenes, blurb writes your information here: Misc/NEWS.d/next/<section-name>/<filename> The "<section-name>" is the name of the section in Misc/NEWS where your entry should go. <filename> contains the current date and time, the bpo number, and a nonce to prevent collisions. These "next" files get merged together into a single aggregate .rst file by the release manager when cutting a release (using "blurb release"). One nice feature of this approach: when you cherry-pick a change, its Misc/NEWS entry in "next" gets cherry-picked along with it. One important change: Misc/NEWS will no longer be checked in. It'll still be present in CPython tarballs; it will be generated by the release manager as part of cutting a release. But as a repository of information, it's been superseded by the various blurb data files. And by regenerating it from data files, we ensure that we'll never ever have a Misc/NEWS conflict ever again! The plan is to leave Misc/NEWS in the CPython repo for maybe another week, to let the current crop of PRs get merged. But new work should switch to using blurb immediately. You can install blurb from pip: % pip3.6 install blurb In fact--please do! //arry/

6 10

How does GitHub count contributors?
by Antoine Pitrou 24 Jun '17

24 Jun '17

Hello, This is a bit of a futile question, but I realize I'm nowhere to be seen in https://github.com/python/cpython/graphs/contributors Is there some map file somewhere that I must update to match my commit e-mail to my GitHub account? Regards Antoine.

4 4

Re: [python-committers] [Python-Dev] New workflow change: Welcome to blurb
by Nick Coghlan 24 Jun '17

24 Jun '17

On 24 June 2017 at 14:01, Craig Rodrigues <rodrigc(a)freebsd.org> wrote: > On Fri, Jun 23, 2017 at 8:24 PM, Larry Hastings <larry(a)hastings.org> wrote: >> >> >> >> We've been talking about addressing this for years. Fixing this was one >> of the goals of the new workflow. And finally, as of right now, the future >> is here. Ladies and gentlemen, I present: blurb. >> >> https://github.com/python/core-workflow/tree/master/blurb > > > Yes, when you have a single NEWS file that needs to get updated, > the process begins to fall apart when you have a pull request type of > workflow > which results in many merge conflicts to the single NEWS file. > > Twisted and Buildbot use towncrier ( https://github.com/hawkowl/towncrier ) > which tries > to solve the same problem as blurb. Aye, towncrier and OpenStack's reno were the two main alternatives we looked at in addition to Larry's offer of creating a tool specifically for CPython: https://github.com/python/core-workflow/issues/6 We ultimately settled on blurb mainly because we wanted to be able to customise various details differently from the way towncrier works, and we figure they're close enough in spirit that folks familiar with one won't have any problems adapting to the other. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

Reminder! Today's the last day for core sprint sign-ups!
by Guido van Rossum 23 Jun '17

23 Jun '17

[Was: Core sprint 2017 - Sep 4 - Sep 9, Menlo Park, California] On Mon, Jun 12, 2017 at 4:04 PM, Lukasz Langa <lukasz(a)langa.pl> wrote: > Hello fellow committers! > I'm organizing another core sprint this year to make Python 3.7 the best > release possible. > > *WHY*: > 1. *Community*. The sprints at the end of PyCon are great but they > mostly get the same people in the room year after year. Many of the most > active contributors never attend conferences. My goal with this sprint is > to bring together many core devs who rarely if ever meet! > 2. *Focus*. When we have sprints at the end of a conference, many of us > are pretty tired and less productive than we could have been without the > late dinners, endless hallway sessions, and so on. Some of the sprinters > are preoccupied with tutoring newcomers. This sprint won't be after a > major conference, and it's only for seasoned CPython core devs--so get to > work! > 3. *Communication*. There are tremendous benefits to getting everyone > together in one big room. Conversations that drag on on python-dev can be > solved quickly in person. Even contentious debates become faster, easier, > and more civil. And meeting face-to-face helps us all feel more connected > to our community. > > *WHY THE BAY AREA*: We have a large population of core contributors > here. Also, I can arrange for Facebook to provide us a "war room" for the > whole week, with full access to the campus during the sprints. That > includes free food for breakfast, lunch, dinner, and snacks, compatible > with almost any dietary restrictions. > > *WHY EARLY SEPTEMBER*: It's almost impossible to find a time that doesn't > overlap with a PyCon. This week worked well last year so we're redoing it > that way. Monday September 4 is Labor Day in the US, which may make it > easier for employees of US companies to attend, as they'd only be taking > off four days instead of five. > > *HOW LONG*: A full week Monday, Sep 4 to Friday, Sep 8 evening. You can > check into your hotel the day before the sprint (Sunday, Sep 3) and check > out the day after (Saturday, Sep 9). > > *HOW BIG*: No fewer than 10, no more than 20. More than 20 people would > be great but it'd be hard for me to organize a sprint that big. > > *WHO PAYS*: The venue, hotels, and food are provided by Facebook. I'm > working on getting flight reimbursements. Last year they were provided by > the Python Software Foundation. Anybody is free to waive their > reimbursement. > > *PLEASE REPLY*: If you're interested in attending and have the commit bit > on GitHub's python/cpython, fill out this Google Form: > https://goo.gl/forms/MzrNtRe0NAmzvGwF2 > > *DISCLAIMER*: I'd like to be able to host everybody. However, if I > receive more than 20 applications, this is not going to be possible. In > this case, the following will happen: > > 1. I will look at your current level of involvement in CPython > development. This includes metrics like commits / PRs, activity on the bug > tracker and python-dev, special role (release manager, infrastructure dev, > etc.). > 2. I will look at your sprint plan and ability to participate in the > entire sprint (per answers to the questions above). > 3. I will gather all this data and leave the final decision to our > Benevolent Dictator (who is also attending the sprint). This is one of > those occasions where having a dictator is useful. > > *DON'T WAIT*: September is closer than you think! Please let me know as > soon as possible so we can start setting up the event. I'm going to close > the sign-up form on June 23rd. > > Organizational-ly yours, > Ł > Vice-Minister of Silly Sprints > > _______________________________________________ > python-committers mailing list > python-committers(a)python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)

1 0

Proposed release schedule for Python 3.5.4
by Larry Hastings 23 Jun '17

23 Jun '17

It's time to start planning the next 3.5 release, 3.5.4. Note that this will be the last 3.5 "bugfix" release; after 3.5.4, the 3.5 branch will only be open for security fixes. 3.5.4 will also be the last release of 3.5 with binary installers. I propose to tag and release 3.5.4 on these dates: 3.5.4rc1 tag Sat July 22 2017 release Sun July 23 2017 3.5.4 final tag Sun Aug 6 2017 release Mon Aug 7 2017 Thus rc1 would be tagged in just over four weeks. As for 3.4-- Lately I've been releasing new versions of 3.5 and 3.4 at the same time. But I'm not sure it's worth the effort to release another 3.4 right now. There have only been two (2) checkins into the 3.4 branch since 3.4.6 was released back in January: f37b0cb230069481609b0bb06891b5dd26320504 bpo-25008: Deprecate smtpd and point to aiosmtpd fa53dbdec818b0f2a0e22ca12a49d83ec948fc91 Issues #27850 and #27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305. The first was a documentation-only change which is already live on docs.python.org. The second changes the _DEFAULT_CIPHERS and _RESTRICTED_SERVER_CIPHERS constants in Lib/ssl.py. A reasonable change, but minor. I'm not convinced it's worth spending the time of many people in the community at large to update 3.4 just for this. If you have any feedback / concerns about this schedule, or if you think it's important that I release 3.4.7 with these minor changes, please reply here. If I don't hear anything back in a day or two I'll go ahead and make this the official schedule. Your friendly neighborhood release manager, //arry/

4 8