Mailman 3 July 2017 - python-committers

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