This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.)
As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You should now be treating the 3.7 branch as if it were already released and in maintenance mode. That means you should only push the kinds of changes that are appropriate for a maintenance release: non-ABI-changing bug and feature fixes and documentation updates. If you find a problem that requires an ABI-altering or other significant user-facing change (for example, something likely to introduce an incompatibility with existing users' code or require rebuilding of user extension modules), please make sure to set the b.p.o issue to "release blocker" priority and describe there why you feel the change is necessary. If you are reviewing PRs for 3.7 (and please do!), be on the lookout for and flag potential incompatibilities (we've all made them).
Thanks again for all of your hard work towards making 3.7.0 yet another great release - coming to a website near you on 06-15!
Release Managerly Yours, --Ned
https://www.python.org/dev/peps/pep-0537/
-- Ned Deily nad@python.org -- []
15.05.18 14:51, Ned Deily пише:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.)
The "What's New in 3.7" document is still not complete. Actually it is far completing. In the previous releases somebody made a thoughtful review of the NEWS file and added all significant changes in What's New, and also removed insignificant entries, reorganized entries, fixed errors, improved wording and formatting. Many thanks to Martin Panter, Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan, Antoine Pitrou, Victor Stinner and others for their great work! But seems in 3.7 this documents doesn't have an editor.
On Thu, 17 May 2018 at 14:31 Serhiy Storchaka <storchaka@gmail.com> wrote:
15.05.18 14:51, Ned Deily пише:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.)
The "What's New in 3.7" document is still not complete. Actually it is far completing. In the previous releases somebody made a thoughtful review of the NEWS file and added all significant changes in What's New, and also removed insignificant entries, reorganized entries, fixed errors, improved wording and formatting. Many thanks to Martin Panter, Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan, Antoine Pitrou, Victor Stinner and others for their great work! But seems in 3.7 this documents doesn't have an editor.
Maybe we should start thinking about flagging PRs or issues as needing a What's New entry to help track when they need one, or always expect it in a PR and ignore that requirement when a 'skip whats new' label is applied. That would at least make it easier to keep track of what needs to be done.
17.05.18 21:39, Brett Cannon пише:
Maybe we should start thinking about flagging PRs or issues as needing a What's New entry to help track when they need one, or always expect it in a PR and ignore that requirement when a 'skip whats new' label is applied. That would at least make it easier to keep track of what needs to be done.
The requirement of flagging PRs or issues as needing a What's New entry doesn't differ in principle from the requirement of creating a What's New entry for these changes. The latter is good, and I'm trying always create a What's New entry for significant enhancement or potentially breaking change. And even I sometimes is unsure and don't document some important changes (like in issue30399). Needed a look of yet one pair of eyes.
As for requiring a What's New entry by default and introducing a 'skip whats new' label, I suppose this will add much nuisance. Most PRs (except docs and tests changes) need a news entry, but most PRs don't need a What's New entry because their are bug fixes. Therefore a 'skip whats new' label will be required much more times than 'skip news' or 'skip issue' labels.
A thing that can help is a tool that makes a structural diff between NEWS files for different versions and between different branches. It will filter out bugfix changes. The simple 'diff' is not well appropriate because entries can be in different order, and news entries now are scattered between several files, and news entries for previous version sometimes should be searched in different files, and sometimes should be searched on a different branch. The text of entries in different versions can also be different because the same issue can change the behavior on the master and backport the part of changes as a bugfix.
Elvis has been working on the What’s New doc at the sprints this week. He should be checking in his edits soon. Stay tuned!
-- Ned Deily nad@python.org -- []
On May 17, 2018, at 14:31, Serhiy Storchaka <storchaka@gmail.com> wrote:
15.05.18 14:51, Ned Deily пише:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.)
The "What's New in 3.7" document is still not complete. Actually it is far completing. In the previous releases somebody made a thoughtful review of the NEWS file and added all significant changes in What's New, and also removed insignificant entries, reorganized entries, fixed errors, improved wording and formatting. Many thanks to Martin Panter, Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan, Antoine Pitrou, Victor Stinner and others for their great work! But seems in 3.7 this documents doesn't have an editor.
We are going to extend for 48 hours the deadline for 3.7.0rc1, that is, until 2018-05-23 23:59 AOE. While we have made tremendous progress towards the release candidate over the past week especially with the huge efforts at the PyCon US Sprints, we still have some important issues to resolve. A stumbling block has been the increased instability in the test suite, primarily in test_asyncio, which has caused delays in merging PRs due to intermittent failures in CI test runs and which has caused widespread buildbot failures. Another factor is that this weekend and Monday are public holidays in many countries, something I did not take into account when drawing up the schedule. (Note that next weekend is a major public holiday in the USA.) So let's plan on using the extra two days to work through the remaining release blockers.
Thanks again! --Ned
On May 15, 2018, at 07:51, Ned Deily <nad@python.org> wrote:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.)
As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You should now be treating the 3.7 branch as if it were already released and in maintenance mode. That means you should only push the kinds of changes that are appropriate for a maintenance release: non-ABI-changing bug and feature fixes and documentation updates. If you find a problem that requires an ABI-altering or other significant user-facing change (for example, something likely to introduce an incompatibility with existing users' code or require rebuilding of user extension modules), please make sure to set the b.p.o issue to "release blocker" priority and describe there why you feel the change is necessary. If you are reviewing PRs for 3.7 (and please do!), be on the lookout for and flag potential incompatibilities (we've all made them).
Thanks again for all of your hard work towards making 3.7.0 yet another great release - coming to a website near you on 06-15!
Release Managerly Yours, --Ned
-- Ned Deily nad@python.org -- []
15.05.18 14:51, Ned Deily пише:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.)
Is it possible to add yet one beta instead?
CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release.
Also there's https://bugs.python.org/issue33612 which appears quite critical.
Regards
Antoine.
Le 23/05/2018 à 13:45, Serhiy Storchaka a écrit :
15.05.18 14:51, Ned Deily пише:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.)
Is it possible to add yet one beta instead?
CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
2018-05-23 13:47 GMT+02:00 Antoine Pitrou <antoine@python.org>:
Also there's https://bugs.python.org/issue33612 which appears quite critical.
Can someone please have a look at my socketserver change? https://github.com/python/cpython/pull/6911
bpo-31151 changed ForkingMixIn and bpo-31233 changed ThreadingMixIn to block on server_closer() for processes/threads. I propose to add a new opt-in option to get the Python 3.6 behaviour. The old behaviour was wrong, but I expect that some people rely on it." https://bugs.python.org/issue33540
Victor
2018-05-23 13:45 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), (...)
I looked at buildbots and I confirm that many of the 3.x buildbots are red:
AMD64 FreeBSD 10.x Shared 3.x AMD64 Windows8.1 Non-Debug 3.x ARMv7 Ubuntu 3.x PPC64 Fedora 3.x s390x RHEL 3.x x86 Gentoo Installed with X 3.x x86 Gentoo Refleaks 3.x AMD64 Windows8.1 Refleaks 3.x
Victor
Ah, Python doesn't compile on Windows anymore :-) https://bugs.python.org/issue33614
Victor
2018-05-23 14:16 GMT+02:00 Victor Stinner <vstinner@redhat.com>:
2018-05-23 13:45 GMT+02:00 Serhiy Storchaka <storchaka@gmail.com>:
CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), (...)
I looked at buildbots and I confirm that many of the 3.x buildbots are red:
AMD64 FreeBSD 10.x Shared 3.x AMD64 Windows8.1 Non-Debug 3.x ARMv7 Ubuntu 3.x PPC64 Fedora 3.x s390x RHEL 3.x x86 Gentoo Installed with X 3.x x86 Gentoo Refleaks 3.x AMD64 Windows8.1 Refleaks 3.x
Victor
On May 23, 2018, at 07:45, Serhiy Storchaka <storchaka@gmail.com> wrote:
15.05.18 14:51, Ned Deily пише:
This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.) Is it possible to add yet one beta instead?
CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release.
it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then.
-- Ned Deily nad@python.org -- []
On May 23, 2018, at 09:13, Ned Deily <nad@python.org> wrote:
On May 23, 2018, at 07:45, Serhiy Storchaka <storchaka@gmail.com> wrote:
Is it possible to add yet one beta instead? CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then.
An update: thanks to a lot of effort over the past day by a number of people (including Victor, Serhiy, Christian, Zach, and others I'm sure I'm forgetting - my apologies), we have addressed all of the "release blocker" issues and all but one of the persistent failures on the 3.7 stable buildbots. We should have the couple of remaining "deferred blockers" including the remaining stable buildbots in green status by later today. At that point, we will be ready to tag 3.7.0rc1 and begin producing the release candidate artifacts.
So this *is* really your last chance: if you know of any true releasing blocking issues for 3.7.0, you have about 12 more hours to log it in the bug tracker as a "release blocker". I'll send out an email once we start the release manufacturing. Any merges to the 3.7 branch after that will be released in 3.7.1 which we tentatively are planning to ship sometime before the end of July (< 2018-07-31). If you do find a critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0, please merge a fix into 3.7 (and other appropriate branches), leave the issue open and marked as "release blocker", and add a note why you think the fix needs to be cherry-picked into 3.7.0.
More later today!
--Ned
P.S. To address a few of the earlier comments on this thread:
Antoine: > Also there's https://bugs.python.org/issue33612 which appears quite critical.
Resolved
Victor: > Can someone please have a look at my socketserver change?
Reviewed and merged
Victor: > I looked at buildbots and I confirm that many of the 3.x buildbots are red:
Yes, but it's the 3.7 buildbots that are of interest now, not the 3.x ones :) And, as noted above, I believe we have cleaned up (or will shortly) the remaining 3.7 stable buildbot failures. Coincidentally, we've also fixed some of the 3.x (master -> 3.8) buildbots.
Victor: > Ah, Python doesn't compile on Windows anymore :-)
Stale files on one of the Windows buildbots -> cleaned up
-- Ned Deily nad@python.org -- []
24.05.18 10:23, Ned Deily пише:
So this *is* really your last chance: if you know of any true releasing blocking issues for 3.7.0, you have about 12 more hours to log it in the bug tracker as a "release blocker". I'll send out an email once we start the release manufacturing. Any merges to the 3.7 branch after that will be released in 3.7.1 which we tentatively are planning to ship sometime before the end of July (< 2018-07-31). If you do find a critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0, please merge a fix into 3.7 (and other appropriate branches), leave the issue open and marked as "release blocker", and add a note why you think the fix needs to be cherry-picked into 3.7.0.
I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it.
- Changes in the AST. Few third-party projects was broken by it and already are fixed. I suppose yet few projects will be changed after 3.7 be released. It is interesting that IPython was broken in different way than other projects. It was needed to reintroduce the docstring in the list of statements, effectively reverting the 3.7 change. IPython allows to enter several statements at prompt, and therefore it compiles them with the 'exec' mode instead of 'single' as the CPython REPL and IDLE shell. Currently CPython doesn't allow you to paste arbitrary script like the following:
if a: b if c: d
You need to add an empty line between top-level complex statements. If one time CPython will add support of pasting several statements without empty lines between, it might need to add the same hack as IPython. I afraid that we might be needed to change AST again, in 3.7.1 or in 3.8.0.
- Pickle support in typing is not perfect. I was going to fix it (I had almost ready code), but lost a chance of doing this before. It can be changed in 3.7.1, but this means that pickles of some derived typing types created in 3.7.0 will be not compatible with future versions (may be 3.7.1 will not break compatibility, but it will be broken in future because we will not specially supported compatibility with 3.7.0).
There is third issue, related to NetBSD, but it is less important.
I think two weeks will be enough for fixing these issues, but not at rc1 stage.
On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka@gmail.com> wrote:
I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. [...]
Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"?
-- Ned Deily nad@python.org -- []
- Pickle support in typing is not perfect. I was going to fix it (I had almost ready code), but lost a chance of doing this before. It can be changed in 3.7.1, but this means that pickles of some derived typing types created in 3.7.0 will be not compatible with future versions (may be 3.7.1 will not break compatibility, but it will be broken in future because we will not specially supported compatibility with 3.7.0).
I think I had fixed this one. At least the examples reported on typing tracker are now fixed. Do you have some other examples that still fail?
-- Ivan
On 24 May 2018 at 12:02, Ned Deily <nad@python.org> wrote:
On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka@gmail.com> wrote:
I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. [...]
Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"?
-- Ned Deily nad@python.org -- []
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
24.05.18 19:02, Ned Deily пише:
On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka@gmail.com> wrote:
I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. [...]
Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"?
For docstring in AST: https://bugs.python.org/issue32911
Inada's patch looked complex (actually it mostly restored the code before his previous change). We didn't know about IPython and we decided that it is not worth to change this code at this stage (after beta2). And definitely it will be later to do this after rc1.
For pickling of typing types: https://bugs.python.org/issue32873
Ivan fixed cases supported before 3.7. They now are backward and forward compatible. But cases not supported before 3.7 (like List[int]) now produce fragile pickles.
But cases not supported before 3.7 (like List[int]) now produce fragile pickles.
List[int] pickled in 3.7 can't be un-pickled in 3.6, but I wouldn't worry too much about this because it never worked in 3.6. I remember you proposed using __getitem__ in __reduce__, but I am not sure it is a better way, although it will fix the above problem.
I don't think this one is a blocker and we can move this discussion back to b.p.o., unless you have some particular concerns.
The AST one however looks more serious.
-- Ivan
On 24 May 2018 at 12:26, Serhiy Storchaka <storchaka@gmail.com> wrote:
24.05.18 19:02, Ned Deily пише:
On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka@gmail.com> wrote:
I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it.
[...]
Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"?
For docstring in AST: https://bugs.python.org/issue32911
Inada's patch looked complex (actually it mostly restored the code before his previous change). We didn't know about IPython and we decided that it is not worth to change this code at this stage (after beta2). And definitely it will be later to do this after rc1.
For pickling of typing types: https://bugs.python.org/issue32873
Ivan fixed cases supported before 3.7. They now are backward and forward compatible. But cases not supported before 3.7 (like List[int]) now produce fragile pickles.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On May 24, 2018, at 12:26, Serhiy Storchaka <storchaka@gmail.com> wrote:
24.05.18 19:02, Ned Deily пише:
On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka@gmail.com> wrote:
I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. [...]
Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"? For docstring in AST: https://bugs.python.org/issue32911
Inada's patch looked complex (actually it mostly restored the code before his previous change). We didn't know about IPython and we decided that it is not worth to change this code at this stage (after beta2). And definitely it will be later to do this after rc1.
We have had many discussions about this issue earlier and, while there were arguments made for more than one approach, I believe we reached agreement that this was a deliberate incompatibility that we and our users could live with. The issue has been closed since 2018-03-18. At some point, we need to move on. However, if additional exposure downstream has identified significant new problems, then the issue should be re-opened and a specific proposal made. BTW, do we know what the iPython folks think about this? But there still seems to be disagreements about whether anything needs to be changed. As I commented yesterday, I *really* don't want to keep revisiting this but I am not going to make a technical call. Without an open "release blocker" issue, though, nothing is going to change for 3.7.0rc1. If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.
For pickling of typing types: https://bugs.python.org/issue32873
Ivan fixed cases supported before 3.7. They now are backward and forward compatible. But cases not supported before 3.7 (like List[int]) now produce fragile pickles.
That issue was closed by Ivan and there have been no comments on it since 2018-04-04. I'll defer to his recent reply in this thread.
-- Ned Deily nad@python.org -- []
On 05/24/2018 10:08 AM, Ned Deily wrote:
If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.
About that. According to the Python Dev Guide:
Whether a bug is a *release blocker* for the current release
schedule is decided by the release manager. Triagers may recommend
this priority and should add the release manager to the nosy list.
https://devguide.python.org/triaging/#priorityOf course, a particular release manager (e.g. Ned here) can change the policy for their releases. But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X. This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
//arry/
On May 24, 2018, at 13:46, Larry Hastings <larry@hastings.org> wrote:
On 05/24/2018 10:08 AM, Ned Deily wrote:
If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.
About that. According to the Python Dev Guide: Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list.
https://devguide.python.org/triaging/#priority Of course, a particular release manager (e.g. Ned here) can change the policy for their releases. But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X. This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
I think we're reading the same words a bit differently. There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not. But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker". It is then on the Release Manager's radar to accept or reject. I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;)
As for 3.6.x and 3.7.x, I would much prefer to have too many proposed "release blocker" issues than to have too few. And the sooner they are reported, the better.
-- Ned Deily nad@python.org -- []
On 24.05.2018 20:09, Ned Deily wrote:
On May 24, 2018, at 13:46, Larry Hastings <larry@hastings.org> wrote:
On 05/24/2018 10:08 AM, Ned Deily wrote:
If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.
About that. According to the Python Dev Guide: Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list.
https://devguide.python.org/triaging/#priority Of course, a particular release manager (e.g. Ned here) can change the policy for their releases. But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X. This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
I think we're reading the same words a bit differently. There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not. But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker". It is then on the Release Manager's radar to accept or reject. I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;)
As for 3.6.x and 3.7.x, I would much prefer to have too many proposed "release blocker" issues than to have too few. And the sooner they are reported, the better.
Ned's interpretation is the one I'm using for submitting such issues (maybe not twelve hours before a final release). What other documented ways would you have to get the attention of a release manager.
Having different interpretations depending on the release manager doesn't look very practically.
Matthias
On 25 May 2018 at 04:09, Ned Deily <nad@python.org> wrote:
On 05/24/2018 10:08 AM, Ned Deily wrote:
If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.
About that. According to the Python Dev Guide: Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list.
https://devguide.python.org/triaging/#priority Of course, a particular release manager (e.g. Ned here) can change the
On May 24, 2018, at 13:46, Larry Hastings <larry@hastings.org> wrote: policy for their releases. But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X. This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
I think we're reading the same words a bit differently. There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not. But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker". It is then on the Release Manager's radar to accept or reject. I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;)
Right, my interpretation of that policy has been that to request RM review of a potential blocker I should:
- set the status to Release Blocker
- add the relevant RM to the nosy list
- add a comment explaining why I think it might be a release blocker and asking the RM to take a look it at
The RM then makes their decision by either commenting to say they're accepting the issue as a blocker, bumping it down to deferred blocker (if they don't think it's a blocker *yet*), or else bumping it down to one of the non-blocking priorities (if they don't agree that it's a blocker at all).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, May 25, 2018, 07:53 Nick Coghlan, <ncoghlan@gmail.com> wrote:
On 25 May 2018 at 04:09, Ned Deily <nad@python.org> wrote:
On 05/24/2018 10:08 AM, Ned Deily wrote:
If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.
About that. According to the Python Dev Guide: Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list.
https://devguide.python.org/triaging/#priority Of course, a particular release manager (e.g. Ned here) can change the
On May 24, 2018, at 13:46, Larry Hastings <larry@hastings.org> wrote: policy for their releases. But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X. This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
I think we're reading the same words a bit differently. There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not. But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker". It is then on the Release Manager's radar to accept or reject. I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;)
Right, my interpretation of that policy has been that to request RM review of a potential blocker I should:
- set the status to Release Blocker
- add the relevant RM to the nosy list
- add a comment explaining why I think it might be a release blocker and asking the RM to take a look it at
The RM then makes their decision by either commenting to say they're accepting the issue as a blocker, bumping it down to deferred blocker (if they don't think it's a blocker *yet*), or else bumping it down to one of the non-blocking priorities (if they don't agree that it's a blocker at all).
That's how I've always done it as well. As Ned said, better safe than sorry by guessing at something being a release blocker than something accidentally being lost in the cracks.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Well, I must admit, I'm a little baffled. The text states unequivocally that the release manager is the only person who decides whether or not a bug is a "release blocker". This means nobody else is permitted to make this decision. So I don't see how somebody else can mark a bug as a "release blocker" without first deciding that it's a "release blocker"--which they're not permitted to do given the rules laid down by the Dev Guide.
But if that's not the intended Core Dev policy, then that's not the intended Core Dev policy. Given that literally everybody else interpreted the text differently than me, this suggests that the text is at the very least ambiguous, if not outright misleading and should be updated. I'll try to put together a PR to bring it more in line with everyone's de facto interpretation.
BTW, this all came up because a core dev marked a minor documentation change as a "release blocker" for the 3.5 branch, stating that they did this "because it'd be nice to see it make it out in the next release". ISTM that opinions vary on what constitutes a "release blocker", and maybe empowering only the release managers to make that call would be a good way forward--which is what ISTM is what the Dev Guide already says anyway. But I guess not!
//arry/
On 05/25/2018 08:26 AM, Brett Cannon wrote:
On Fri, May 25, 2018, 07:53 Nick Coghlan, <ncoghlan@gmail.com <mailto:ncoghlan@gmail.com>> wrote:
On 25 May 2018 at 04:09, Ned Deily <nad@python.org <mailto:nad@python.org>> wrote: On May 24, 2018, at 13:46, Larry Hastings <larry@hastings.org <mailto:larry@hastings.org>> wrote: > On 05/24/2018 10:08 AM, Ned Deily wrote: >> If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue. > > About that. According to the Python Dev Guide: > Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list. > > https://devguide.python.org/triaging/#priority > Of course, a particular release manager (e.g. Ned here) can change the policy for their releases. But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X. This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5). I think we're reading the same words a bit differently. There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not. But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker". It is then on the Release Manager's radar to accept or reject. I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;) Right, my interpretation of that policy has been that to request RM review of a potential blocker I should: - set the status to Release Blocker - add the relevant RM to the nosy list - add a comment explaining why I think it might be a release blocker and asking the RM to take a look it at The RM then makes their decision by either commenting to say they're accepting the issue as a blocker, bumping it down to deferred blocker (if they don't think it's a blocker *yet*), or else bumping it down to one of the non-blocking priorities (if they don't agree that it's a blocker at all).That's how I've always done it as well. As Ned said, better safe than sorry by guessing at something being a release blocker than something accidentally being lost in the cracks.
Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com <mailto:ncoghlan@gmail.com> | Brisbane, Australia _______________________________________________ python-committers mailing list python-committers@python.org <mailto:python-committers@python.org> https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On May 30, 2018, at 1:15 PM, Larry Hastings <larry@hastings.org> wrote:
ISTM that opinions vary on what constitutes a "release blocker", and maybe empowering only the release managers to make that call would be a good way forward--which is what ISTM is what the Dev Guide already says anyway. But I guess not!
I think that RMs are empowered to decide what is a “real" release blocker, but you need some mechanism to flag an issue as potentially a release blocker for the RM to make a decision on it. Making a decision on that potentially release blocker should also itself be a release blocker (because if it’s possibly a release blocker, then we should treat it as such until the person empowered to make that call has decided one way or another).
So I think for the system to work, you need to either allow anyone to flag an issue as a release blocker, and the RM is empowered to say “No this really isn’t” and unflag it, or you need two flags, for release blocker, and maybe release blocker, and both block the release.
In terms of process, it's always good to have a method to escalate a question to higher management in a way which doesn't require the manager to first parse long text messages.
So a status such as "Potential Release Blocker" or "RM Review" sounds like a good way forward.
Of course a friendly ping via some other channel usually also helps get attention :-)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 30 2018)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On Wed, 30 May 2018 at 10:21 Donald Stufft <donald@stufft.io> wrote:
On May 30, 2018, at 1:15 PM, Larry Hastings <larry@hastings.org> wrote:
ISTM that opinions vary on what constitutes a "release blocker", and maybe empowering only the release managers to make that call would be a good way forward--which is what ISTM is what the Dev Guide already says anyway. But I guess not!
I think that RMs are empowered to decide what is a “real" release blocker, but you need some mechanism to flag an issue as potentially a release blocker for the RM to make a decision on it. Making a decision on that potentially release blocker should also itself be a release blocker (because if it’s possibly a release blocker, then we should treat it as such until the person empowered to make that call has decided one way or another).
And this is how I have always interpreted it. Larry is totally within his rights to say "that is not a release blocker" and switch it to not being one. At the end of the day it's Larry who presses the proverbial "Release" button and that label technically means nothing if he chooses to ignore it.
So I think for the system to work, you need to either allow anyone to flag an issue as a release blocker, and the RM is empowered to say “No this really isn’t” and unflag it, or you need two flags, for release blocker, and maybe release blocker, and both block the release.
Yep, or as MAL suggested, a "potential release blocker" or something where we expect only RMs to push something all the way up to an actual "release blocker".
On 05/30/2018 11:59 AM, Brett Cannon wrote:
On Wed, 30 May 2018 at 10:21 Donald Stufft <donald@stufft.io <mailto:donald@stufft.io>> wrote:
So I think for the system to work, you need to either allow anyone to flag an issue as a release blocker, and the RM is empowered to say “No this really isn’t” and unflag it, or you need two flags, for release blocker, and maybe release blocker, and both block the release.Yep, or as MAL suggested, a "potential release blocker" or something where we expect only RMs to push something all the way up to an actual "release blocker".
I suggest we simply use the existing "critical" priority to also mean "potential release blocker". If not, what would be the salient difference between a "critical" bug and a "potential release blocker" bug?
//arry/
On 05/30/2018 10:21 AM, Donald Stufft wrote:
On May 30, 2018, at 1:15 PM, Larry Hastings <larry@hastings.org <mailto:larry@hastings.org>> wrote:
ISTM that opinions vary on what constitutes a "release blocker", and maybe empowering only the release managers to make that call would be a good way forward--which is what ISTM is what the Dev Guide already says anyway. But I guess not!
I think that RMs are empowered to decide what is a “real" release blocker, but you need some mechanism to flag an issue as potentially a release blocker for the RM to make a decision on it. Making a decision on that potentially release blocker should also itself be a release blocker (because if it’s possibly a release blocker, then we should treat it as such until the person empowered to make that call has decided one way or another).
So I think for the system to work, you need to either allow anyone to flag an issue as a release blocker, and the RM is empowered to say “No this really isn’t” and unflag it, or you need two flags, for release blocker, and maybe release blocker, and both block the release.
Yes, ISTM that the Dev Guide covers this. The section on priority says:
Triagers may recommend this priority and should add the release
manager to the nosy list.In other words: if a dev thinks an issue should be a release blocker for version X, they should add the RM to the nosy list and make a comment recommending the issue be escalated to release blocker. I thought it was telling that it /doesn't/ instruct triagers to mark the issue as a release blocker themselves.
//arry/
On May 30, 2018, at 3:03 PM, Larry Hastings <larry@hastings.org> wrote:
Yes, ISTM that the Dev Guide covers this. The section on priority says: Triagers may recommend this priority and should add the release manager to the nosy list. In other words: if a dev thinks an issue should be a release blocker for version X, they should add the RM to the nosy list and make a comment recommending the issue be escalated to release blocker. I thought it was telling that it doesn't instruct triagers to mark the issue as a release blocker themselves.
That seems a rather poor way of handling it TBH. A key thing is that an escalation for a decision should itself be a release blocker, because if someone thinks the issue might be, then we should get a decision on whether it is or not before the release goes out. Relying on a comment seems far too easy for the release manager to accidentally miss it or forget about it.
On May 30, 2018, at 15:09, Donald Stufft <donald@stufft.io> wrote:
On May 30, 2018, at 3:03 PM, Larry Hastings <larry@hastings.org> wrote:
Yes, ISTM that the Dev Guide covers this. The section on priority says: Triagers may recommend this priority and should add the release manager to the nosy list. In other words: if a dev thinks an issue should be a release blocker for version X, they should add the RM to the nosy list and make a comment recommending the issue be escalated to release blocker. I thought it was telling that it doesn't instruct triagers to mark the issue as a release blocker themselves.
That seems a rather poor way of handling it TBH. A key thing is that an escalation for a decision should itself be a release blocker, because if someone thinks the issue might be, then we should get a decision on whether it is or not before the release goes out. Relying on a comment seems far too easy for the release manager to accidentally miss it or forget about it.
Yes. And I think Donald's earlier description of the current process was 100% correct. It is true that, at some level, the current "release blocker" could be broken into two separate states, a "release blocker proposed" and "release blocker accepted". But why? In nearly a dozen years of following the bug tracker and the Python process, I don't recall this ever coming up before. As a practical matter, there is absolutely no ambiguity as the issue history shows who set the priority to "release blocker". Again, it's a near foolproof way (since RM's are not allowed to make a release with a "release blocker" open against that release) to ensure the issue has been evaluated by the RM. And it has worked well for many people for many reasons. And it just doesn't happen very often, i.e. we don't have many release blockers.
I think the only reason this came up was because of our policy, enforced by GitHub settings, that merges to "security fix only" branches may only be performed by the release manager, unlike other branches. And in this case, the core developer just wanted to make sure that the release manager saw and acted on the outstanding PR for the security branch. I think that action made perfect sense to me.
So, I really really don't think there's a problem today that needs solving and, worse, the suggestions so far add complexity with no benefit at all as far as I can see. May I respectfully suggest that we just drop this discussion and move on, please?
-- Ned Deily nad@python.org -- []
On May 24, 2018, at 03:23, Ned Deily <nad@python.org> wrote:
On May 23, 2018, at 07:45, Serhiy Storchaka <storchaka@gmail.com> wrote:
Is it possible to add yet one beta instead? CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then. An update: thanks to a lot of effort over the past day by a number of
On May 23, 2018, at 09:13, Ned Deily <nad@python.org> wrote: people (including Victor, Serhiy, Christian, Zach, and others I'm sure I'm forgetting - my apologies), we have addressed all of the "release blocker" issues and all but one of the persistent failures on the 3.7 stable buildbots. We should have the couple of remaining "deferred blockers" including the remaining stable buildbots in green status by later today. At that point, we will be ready to tag 3.7.0rc1 and begin producing the release candidate artifacts.
Further update: some good news and some changes.
The good news is that we have resolutions for all of the previous release and deferred blockers. Thanks to a number of people for continuing to help get the remaining stable buildbot issues taken care of along with some lingering bugs.
The not-quite-as-good news is that we have had more discussions about some unexpected incompatibilities that have shown up with downstream user testing with the AST docstrings changes in place (see bpo-32911). We have had some previous discussions about the expected user impact and, earlier in the beta phase, I encouraged us to stay the course with the feature as implemented. But I am now persuaded that we owe it to our users to take one more look at this to make sure we do not force them to make changes for 3.7 and then once again for 3.8. More details are in the bug tracker issue; I strongly encourage those of us who have been involved with this to "vote" there on the proposal to either (A) proceed with the release of the current implementation in 3.7.0 or (B) revert the feature in 3.7.0 and retarget for 3.8. Should the consensus be to revert (B), we will plan to have one more fast-track beta release (b5) prior to the release candidate, in order to allow downstream users to test their projects with the removal. PLEASE, keep the discussion about this on the bug tracker (and not here!) and keep it brief so we can move forward quickly. Because of the upcoming 3-day holiday weekend in some countries, I have set Tue 2018-05-29 18:00 UTC as a cutoff for "voting" but, if a clear consensus emerges earlier, we will likely cut the discussion short. So chime in now on the bug tracker if you have a stake in this issue.
https://bugs.python.org/issue32911
This does mean that yesterday's "last chance" has been extended a bit, at most a few days. I will let you know as soon as we have made a decision about the feature and will provide updated 3.7.0 schedule info at that time.
--Ned
-- Ned Deily nad@python.org -- []
participants (11)
-
Antoine Pitrou -
Brett Cannon -
Donald Stufft -
Ivan Levkivskyi -
Larry Hastings -
M.-A. Lemburg -
Matthias Klose -
Ned Deily -
Nick Coghlan -
Serhiy Storchaka -
Victor Stinner