Mailman 3 July 2017 - python-committers

Dismiss review if a PR is modified
by Victor Stinner 19 Jul '17

19 Jul '17

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 19 Jul '17

19 Jul '17

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 18 Jul '17

18 Jul '17

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 18 Jul '17

18 Jul '17

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 18 Jul '17

18 Jul '17

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 18 Jul '17

18 Jul '17

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 17 Jul '17

17 Jul '17

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 17 Jul '17

17 Jul '17

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 16 Jul '17

16 Jul '17

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 15 Jul '17

15 Jul '17

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