Mailman 3 July 2017 - python-committers

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

Aug. 22, 2017

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

Please edit the commit message when merge a PR
by Serhiy Storchaka Aug. 3, 2017

Aug. 3, 2017

When a PR is consistent on several commits, the final commit message composed by GitHub contains messages of all these commits: "fix typo", "address yyy comments", "revert zzz". If the initial commit message contained errors (e.g. absent issue number), it is easy to edit the title and text of a PR, but the initial commit message lefts unchanged. GitHub allows to edit the commit message of squashed commit, and please don't ignore this possibility. Otherwise the commit message in the repository will be ugly if not worse.

7 8

New workflow - some questions
by Paul Moore July 31, 2017

July 31, 2017

I'm just looking at doing some work for the first time under the new workflow. Most things look fine - I'm familiar with git/github, so there's nothing startling in there, but I do have a few small questions: 1. Section 32.2 in the Git bootcamp section - is there any reason to use git@github URLs for the clones? I normally always use https://github.com URLs, as they work with my proxy at work. 2. Section 32.10, I generally use "Compare and create pull request" from my clone's github page, as that seems simpler. Is there any reason for starting from the cpython repo - the process working that way (which I wasn't even aware of!) seems more complex. I can't see that it matters much, but I wouldn't want to mess up a PR if there *is* a difference in the results. 3. The new blurb tool - I presume I'll need to set that up somewhere/somehow, and use it to create a news entry. But I can't find any docs on it at all :-( There may be other stuff - I've been watching the core-workflow list, and it feels like there's some awfully complex stuff being discussed. But so far it looks pretty straightforward and "as expected" - which is a credit to Brett and the others who've set all this up! Thanks, Paul

6 7

AppVeyor was unable to build non-mergeable pull request
by Victor Stinner July 26, 2017

July 26, 2017

Hi, It's the second time today that I get this error on a PR: "continuous-integration/appveyor/pr — AppVeyor was unable to build non-mergeable pull request" With such failure, it's not possible to merge a PR. The error just occurred on a 2.7 change which is a single commit on top of the update to date 2.7 head: https://github.com/python/cpython/pull/2877 For the other PR, I used the workaround found at: http://help.appveyor.com/discussions/problems/4830-stuck-on-appveyor-was-un… => close the PR, reopen the PR It works around the issue, but it spams Travis CI which has to abort running jobs, and then restarts new jobs from scratch. $ git log commit dc72f12b877cacdc3746e152a9379f4c3083fa22 <= my change Author: Victor Stinner <victor.stinner(a)gmail.com> Date: Wed Jul 26 02:20:55 2017 +0200 bpo-30778: Skip test_bsddb3 on Windows XP commit 0666d0e50432e3b0109db96b8e48fb6c496bd49c <= upstream HEAD Author: Aditya Hase <aditya(a)adityahase.com> Date: Wed Jul 26 02:29:52 2017 +0530 bpo-30304: Improve TestCase.assertMultiLineEqual docs (GH-2847) Mention that TestCase.assertMultiLineEqual method is used by default when comparing Unicode string when comparing Unicode strings with assertEqual. (...) Victor

3 4

RELEASED] Python 3.4.7rc1 and Python 3.5.4rc1 are now available
by Larry Hastings July 25, 2017

July 25, 2017

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm relieved to announce the availability of Python 3.4.7rc1 and Python 3.5.4rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. Python 3.5.4 will be the final 3.5 release in "bug fix" mode. After 3.5.4 is released, Python 3.5 will also move into "security fixes mode". Both these releases are "release candidates". They should not be considered the final releases, although the final releases should contain only minor differences. Python users are encouraged to test with these releases and report any problems they encounter. You can find Python 3.4.7rc1 here: https://www.python.org/downloads/release/python-347rc1/ And you can find Python 3.5.4rc1 here: https://www.python.org/downloads/release/python-354rc1/ Python 3.4.7 final and Python 3.5.4 final are both scheduled for release on August 6th, 2017. Happy Pythoning, //arry/

4 3

Travis-CI compiles twice
by Antoine Pitrou July 24, 2017

July 24, 2017

Hi, I've noticed that Travis-CI (sometimes?) compiles CPython twice. Example in https://travis-ci.org/python/cpython/jobs/256552880 First compilation in the "./configure && make" step: https://travis-ci.org/python/cpython/jobs/256552880#L1103 Second compilation in "make buildbottest" step: https://travis-ci.org/python/cpython/jobs/256552880#L1622 This probably loses a minute or two. Regards Antoine.

6 8

My (positive) feedback on the new CPython workflow
by Victor Stinner July 24, 2017

July 24, 2017

Hi, 2017-07-18 11:36 GMT+02:00 Antoine Pitrou <antoine(a)python.org>: > Can I take the opportunity to say thank you again (both you and Larry) > for the "blurb" tool? It really makes an important difference when > contributing. > > Regards > > Antoine. I concur with Antoine, I'm now *very* happy with the new workflow. The code became better, many things are much simpler for me (especially the tasks that I don't have to do myself anymore ;-)), my productivity increases and I see more and more active contributors, much more than before the move to GitHub and new workflow! == Introduction == Two friends asked me recently how is the new Python workflow going. Somehow, I decided to not express myself on the topic to avoid dummy knee-jerk reaction like "it sucks, it was better before, xxx doesn't work, now I have to xxx, etc." It took me at least 3 months to be used to the new workflow, while tools were developed and enhanced, and the workflow was adjusted based on our early feedback. So, here is my feedback :-) == pre-commit CI: less regressions == >From a pure technical point of view, IMHO pre-commit CI on Linux (Travis CI) and Windows (AppVeyor) is a *MAJOR* enhancement. (I don't count macOS, since it's not mandatory yet.) For example, before GitHub, it was common to break Windows since too few core developers were running tests *manually* on Windows. It's hard to prove my point, so try to trust me: we reduce a lot the number of regressions introduced by new changesets. Before, every two weeks, we had to rush to push fixes in urgency (which sometimes leaded to bad code which required multiple iterations until we find the best fix). It was especially annoying when a dev pushed a big change just before being away for 8-12 hours, which means having to push a fix without the review of the change author :-( == More contributors, more contributions, faster reviewed/merged == In term of contributions, I looked at statistics yesterday and it became clear the number of different authors is significantely much higher, around 25 contributors / month before, now closer to 50: https://www.openhub.net/p/python/contributors/summary Well, Git allows to store the original author, so statistics are simplify higher just because previously the tools failed to identify the real author. But I'm watching the bug tracker, pull requests, and Git commits: there are a lot of *new* contributors, we get more contributions, and we are *faster* to integrate them. I also saw again inactive core contributors starting to review again, or even write new PRs! It's a very good sign of the good health of our project! More generally, the whole development seems to be more active, more productive and more *healthy*. == Better scale horizontally == The new workflow better scales horizontally since we delegated much more work to the contributor. Previously the core developers were more the bottleneck. Tasks delegated to the contributors: * create the PR itself (can you still remind when we had to download a patch file and create a commit? ;-)), * write the commit message (I always hated to do that without any kind of review...), * add the NEWS entry (before it was common to explicitly ask to *not* write it... to avoid conflicts with Misc/NEWS...). * most contributors create backports (using cherry-pick) themself. Before, this painful/error-prone task was usually done by a single developer without any review, without pre-commit tests, etc. Note: I didn't see any contributor complaining about having to do these tasks. It seems like it's more the opposite, they are happy to be more *involved* in the project! == GitHub == I never had to explain how to create an account on GitHub, nor how to create a PR. Signing the CLA doesn't seem to be a blocker point neither, contributors are able to sign it and the bot tracks correctly the CLA status (thanks Brett for the bot! it's nice to feel safe for legal issues ;-)). Maybe we have an excellent documentation. Maybe developers already know well the GitHub platform. Even for backports, I didn't have to explain how to cherry-pick a commit, but it was common that I pointed to the devguide section when I proposed the author to do the backport himself/herself. Having explicitly a list of "Approve" and "Requet changes" votes helps to *quickly* have an overview of the review status. I'm just not unconfortable with the fact that an approval is kept even if the PR is modified after the review :-/ I would expect a list a notice "changed modified after the review" or something like that. At least, for my own reviews, to remind me to review again. The [First time contributor] label on PR helps to remind Misc/ACKS: ask the author to add himself/herself to ACKS. Compared to Rietveld, GitHub review tool is as "a good" (not much better, not much worse). Sometimes, I'm lost in reviews: my comments are hidden, I have to unfold many widgets. But it's not that bad. It seems like avoiding rebase works around some of these issues. == Git branches == Having to create a local Git branch, push it to my repository and create PR is more work than attaching a patch file to bugs.python.org. It requires to be more organized to track my "local" Git branches. I'm now trying to remove a local branch after pushing the PR, since it also exists in my "haypo" remote anyway. It helps to have a shorter list of branches. I also wrote a shell script to run "git fetch haypo --prune" to remove "merged" branches (technically, I have to click on a button to remove my branch, after I merge my own PR). Sometimes, I also see branches in the upstream repository (python/cpython), but it seems that we have less and less of them. == NEWS.d and blurb == Thank you Larry Hastings, Brett Cannon and others who helped to write and integrate blurb: no more Misc/NEWS conflict, it's just amazing :-) We *all* wanted that for *years*! Victor

10 17

Python 3.5.4rc1 and 3.4.7rc1 slipping by a day, to July 24 2017
by Larry Hastings July 24, 2017

July 24, 2017

Release engineering for 3.5.4rc1 and 3.4.7rc1 took a lot longer than expected, because this is the first release using "blurb", and it turned out there was a lot of work left to do and a couple dark corners yet to stumble over. 3.5.4rc1 and 3.4.7rc1 will be released Monday, July 24, 2017. The release dates for 3.5.4 final and 3.4.7 final are not expected to change. Sorry about that, //arry/

1 0

Un-available till End of August -2017
by Senthil Kumaran July 22, 2017

July 22, 2017

Hello Python Committers, I have been inactive (unsubscribed from all python.org) mailing list since May 2017. I had some study / other commitments that took too much time and I decided to rest a little from volunteering efforts. I just wanted to share this and I should perhaps inform active members earlier. I will become active towards the end of August 2017. Thank you, Senthil

2 1

I just gave Gareth Rees traige privileges on the tracker
by R. David Murray July 20, 2017

July 20, 2017

I haven't actually heard back from him yet since I just emailed him, but I've never had anyone turn down triage privs :) The trigger was that I closed two issues this week that he comment on that it would have been nice if he had been able to just close himself. I've looked at some of his other tracker contributions as well, and they look to be of high quality. He hasn't made a huge number of contributions on the tracker, so I'm hoping this will encourage him to continue to be more active ;) I wasn't sure if a note like this would be considered noise on this list, but Victor told me in IRC that it helps him notice people, so I agreed I should post here. --David

2 1

Dismiss review if a PR is modified
by Victor Stinner July 19, 2017

July 19, 2017

2017-07-18 21:21 GMT+02:00 R. David Murray <rdmurray(a)bitdance.com>: > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner <victor.stinner(a)gmail.com> wrote: >> I'm just not unconfortable with the fact that an approval is kept even >> if the PR is modified after the review :-/ I would expect a list a >> notice "changed modified after the review" or something like that. At >> least, for my own reviews, to remind me to review again. > > This could be changed if we have consensus to do so. Github has a > setting that will cause existing approvals to be "dismissed" if > a new commit is pushed. > >> Compared to Rietveld, GitHub review tool is as "a good" (not much >> better, not much worse). Sometimes, I'm lost in reviews: my comments >> are hidden, I have to unfold many widgets. But it's not that bad. It >> seems like avoiding rebase works around some of these issues. > > I much prefer rietveld over github reviews, but I also much prefer the > integration between the bug tracker and github over the minimal > integration we had for rietveld. Thanks to all the people who made > that happen, and especially Brett for leading it. I am in favor of making this change :-) Victor

4 5

GitHub blog post on managing email notifications
by Brett Cannon July 19, 2017

July 19, 2017

Thought people might be interested in this post (specifically the email header info) since I know some have said they have had issues in managing email notifications: https://github.com/blog/2399-managing-large-numbers-of-github-notifications

2 1

How do I kill an AppVeyor build?
by Antoine Pitrou July 18, 2017

July 18, 2017

Hi, It seems only some select people have the ability to kill or re-launch AppVeyor builds? Regards Antoine.

4 9

"Invalid symmetric difference expression" on Travis-CI
by Antoine Pitrou July 18, 2017

July 18, 2017

Hi, I've just got this weird error on Travis-CI (the build itself is still marked green, which is great :-D): https://travis-ci.org/python/cpython/jobs/254906991 """ $ set -e if ! git diff --name-only $TRAVIS_COMMIT_RANGE | grep -qvE '(\.rst$)|(^Doc)|(^Misc)' then echo "Only docs were updated, stopping build process." exit fi ./configure --with-pydebug make -j4 make -j4 regen-all clinic changes=`git status --porcelain` if ! test -z "$changes" then echo "Generated files not up to date" echo "$changes" exit 1 fi fatal: Invalid symmetric difference expression 8a8d28501fc8ce25926d168f1c657656c809fd4c...84e0e7a063215809b81e59ab7f59c8bf44492aa8 Only docs were updated, stopping build process. """ Regards Antoine.

1 0

CLA bot bug for a particular contributor
by Antoine Pitrou July 18, 2017

July 18, 2017

Hi, How can I get the CLA bot to fix its knowledge for a particular contributor? bugs.python.org user Gareth Rees (https://bugs.python.org/user14554) has signed the CLA and filled in his GitHub username "gareth-rees". However, a PR filed by Gareth (https://github.com/python/cpython/pull/2741) has the "CLA not signed" label added. I could fix that particular label myself but am I wrong in thinking that further PRs would still have the wrong label assigned? Regards Antoine.

2 1

"trivial" label replaced with "skip issue"
by Brett Cannon July 18, 2017

July 18, 2017

In preparation of fully moving over to blurb and per-file news entries (I don't have an ETA from Larry on when he plans to do explode Misc/NEWS into individual files), the "trivial" label has been replaced with a "skip issue" label to signal that the issue number check should be skipped. The plan is that when we start having a status check for news entries there will be a "skip news" label to skip that status check. Dropping the all-inclusive "trivial" label helps keep us honest and only skip checks that are truly appropriate for a PR since these are skipping information-tracking things. I've also gone ahead and make the issue number check required on all branches since I think Bedevere has proven itself to be reliable enough to be a blocker and since we have the "skip" labels as an escape hatch.

4 7

AppVeyor off?
by Antoine Pitrou July 17, 2017

July 17, 2017

Hi, Is AppVeyor turned off these days? I don't see a build on https://github.com/python/cpython/pull/2417 Regards Antoine.

3 3

[RELEASE] Python 3.6.2 is now available
by Ned Deily July 17, 2017

July 17, 2017

On behalf of the Python development community and the Python 3.6 release team, I am happy to announce the availability of Python 3.6.2, the second maintenance release of Python 3.6. 3.6.0 was released on 2016-12-22 to great interest and we are now providing the second set of bugfixes and documentation updates for it; the first maintenance release, 3.6.1, was released on 2017-03-31. Detailed information about the changes made in 3.6.2 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-2 Please see "What’s New In Python 3.6" for more information about the new features in Python 3.6: https://docs.python.org/3.6/whatsnew/3.6.html You can download Python 3.6.2 here: https://www.python.org/downloads/release/python-362/ The next maintenance release of Python 3.6 is expected to follow in about 3 months, around the end of 2017-09. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ Enjoy! P.S. If you need to download the documentation set for 3.6.2 immediately, you can always find the release version here: https://docs.python.org/release/3.6.2/download.html The most current updated versions will appear here: https://docs.python.org/3.6/ -- Ned Deily nad(a)python.org -- []

1 0

Python 3.3.7 release schedule and end-of-life
by Ned Deily July 16, 2017

July 16, 2017

Python 3.3 is fast approaching its end-of-life date, 2017-09-29. Per our release policy, that date is five years after the initial release of 3.3, 3.3.0 final on 2012-09-29. Note that 3.3 has been in security-fix only mode since the 2014-03-08 release of 3.3.5. It has been a while since we produced a 3.3.x security-fix release and, due to his commitments elsewhere, Georg has agreed for me to lead 3.3 to its well-deserved retirement. To that end, I would like to schedule its next, and hopefully final, security-fix release to coincide with the already announced 3.4.7 security-fix release. In particular, we'll plan to tag and release 3.3.7rc1 on Monday 2017-07-24 (UTC) and tag and release 3.3.7 final on Monday 2017-08-07. In the coming days, I'll be reviewing the outstanding 3.3 security issues and merging appropriate 3.3 PRs. Some of them have been sitting as patches for a long time so, if you have any such security issues that you think belong in 3.3, it would be very helpful if you would review such patches and turn them into 3.3 PRs. As a reminder, here are the guidelines from the devguide as to what is appropriate for a security-fix only branch: "The only changes made to a security branch are those fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch. You should also consider fixing hard-failing tests in open security branches since it is important to be able to run the tests successfully before releasing." Note that documentation changes, other than any that might be related to a security fix, are also out of scope. Assuming no new security issues arise prior to the EOL date, 3.3.7 will likely be the final release of 3.3. And you really shouldn't be using 3.3 at all at this point; while downstream distributors are, of course, free to provide support of 3.3 to their customers, in a little over two months when EOL is reached python-dev will no longer accept any issues or make any changes available for 3.3. If you are still using 3.3, you really owe it to your applications, to your users, and to yourself to upgrade to a more recent release of Python 3, preferably 3.6! Many, many fixes, new features, and substantial performance improvements await you. https://www.python.org/dev/peps/pep-0398/ https://devguide.python.org/devcycle/#security-branches -- Ned Deily nad(a)python.org -- []

2 1

Should I make a 3.4.7rc1 next weekend?
by Larry Hastings July 15, 2017

July 15, 2017

I'm scheduled to tag and release 3.5.4rc1 next weekend. I've been releasing 3.4 and 3.5 at the same time for the last year; this is convenient for me as it halves the frequency with which I have to put on the "release manager" hat. There are currently no scheduled dates to release 3.4.7. The reason being that until very recently there was almost no work done in 3.4 since 3.4.6 was tagged. But! The reason for /that/ was because of a change in the workflow: once we switched to Github, for branches that are in security-fixes-only mode, only the Release Manager is allowed to accept PRs into that branch. It turned out there were a bunch of PRs waiting for my approval. After a flurry of accepted PRs, I have now accrued about ten fresh security fixes in the 3.4 branch. (Mostly from Victor, but also Serhiy, and one from Barry--thanks everyone!) There are now no outstanding security fix PRs against 3.4. Since I'm releasing 3.5.4rc1 next weekend, I wouldn't mind /also/ releasing 3.47rc1 next weekend. That would put 3.4.7 final the same day as 3.5.4 final: just over three weeks from now, releasing on Sunday August 5. I realize it's not much notice, and that's normally not how we do things in the CPython world. (Sorry for the short notice--it's my fault for not adjusting to the new workflow quickly enough.) Anyway the point of this email is to call for a vote. Which of these statements do you agree with: * Larry should tag and release 3.4.7rc1 next weekend. * Larry should schedule 3.4.7rc1 for a month from now, to give people time to get their work in. In particular, Victor and Serhiy, I'm interested in your votes. You both get veto powers for the short notice--if either of you say "do it a month from now" then it'll be a month from now. Also, if anybody has security fixes you want to get in to the next release of 3.4, but you haven't made a PR yet, please reply and describe them. (Please reply to list if appropriate, but if it should be kept quiet please reply to me directly.) Braising in my own juices at EuroPython, //arry/

3 3

Reminder: 3.5.4rc1 will be tagged next Saturday, July 22 2017
by Larry Hastings July 12, 2017

July 12, 2017

Just a quick reminder. I'll be tagging 3.5.4rc1 next Saturday, July 22. 3.5.4 final will be the last release of 3.5.4 that accepts bugfixes; after that, the 3.5 branch will transition to security-fixes-only mode. If you have bugfixes you want to ship with 3.5.4, please get them committed in the next nine days. Happy hacking, //arry/

1 0

[RELEASE] Python 3.6.2rc2 is now available for testing
by Ned Deily July 8, 2017

July 8, 2017

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.2rc2. 3.6.2rc2 is the second release candidate for Python 3.6.2, the next maintenance release of Python 3.6. 3.6.2rc2 includes fixes for three security-related issues resolved since the previous release candidate; see the change log (link below). While 3.6.2rc2 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.2rc2 here: https://www.python.org/downloads/release/python-362rc2/ and its change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-2-release-ca… 3.6.2 is now planned for final release on 2017-07-17 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

3.6.2 update: 3.6.2rc2 coming
by Ned Deily July 6, 2017

July 6, 2017

As you may recall, 3.6.2rc1 was released on 2017-06-17 with an expected release date of 3017-06-30 for 3.6.2 final. As you also may recall, 3.6.2rc1 was delayed a bit to address some security issues including updating our version of libexpat. Shortly after 3.6.2rc1 was released, the expat project released another version of libexpat fixing another security problem. Also since 3.6.2rc1, fixes for several other security issues in Python 3.6 itself have become available and it would be better to get them out sooner rather than later. Therefore, I have decided to do a second release candidate with select fixes cherry-picked from the 3.6 branch; continue to merge bug fixes and doc fixes into 3.6 as usual for release in 3.6.3. Since there haven't been regressions reported so far with 3.6.2rc1, we will plan to compress the rest of the release cycle. Expect to see 3.6.2rc2 available within the next couple of days (2017-07-04 expected) and, assuming no new issues, 3.6.2 final about a week later (around 2017-07-11). --Ned -- Ned Deily nad(a)python.org -- []

2 1

Revert changes which break too many buildbots
by Victor Stinner July 5, 2017

July 5, 2017

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