[python-committers] Re: Proposed tiered platform support
On Mar 25, 2022, at 15:32, Brett Cannon wrote: > Thanks to Petr, and Victor, the platforms that are still looking for a total > of two maintainers over at https://github.com/python/peps/pull/2442/files are: > • arch64-apple-darwin clang [...] I added this comment to the PR: If x86_64-apple-darwin is a Tier 1 platform, then this must be as well. As of today, nearly all Macs being manufactured by Apple are of this architecture (i.e. Apple Silicon) and Apple has made clear that the few remaining legacy Intel-based Macs still being offered will be replaced in the near future (likely by the end of 2022). So, eventually x86_64-apple-darwin will fade in importance as older Macs are retired but that will take many years. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/IXZIHXFZJM27YYV2JNYJYWNLZWPZT3V6/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Python 3.6 rides into the sunset
While there are many reasons to welcome the end of 2021, I would like to give a shout-out to Python 3.6 which officially reached end-of-life on 2021-12-23, 6.5 years after its development began and exactly five years after its initial release. Building on the success of previous Python 3 releases, 3.6 added many new features and improvements too numerous to list: over 1 commits by some 160 contributors, including one of the most popular features in recent Python releases, f-strings (thanks, EVS!). I think it is fair to say that, with Python 3.6, the long transition from Python 2 was finally settled. As release manager for 3.6, I would like to personally thank all those contributors, and mostly volunteers: you made my job an easy one with your overwhelmingly positive attitude and support. I would also like to thank the authors and maintainers of the many third-party packages that were updated to support 3.6 as well as the downstream distributors of Python whose rapid uptake and release of 3.6 in their distributions was crucial to its success. I would also like to thank those who helped get the 3.6 releases out the door, in particular, Steve Dower for manufacturing the Windows packages, Julien Palard for managing our on-line documentation build process, Elvis Pranskevichus and Yury Selivanov for taking on the thankless task of assembling and editing the 3.6 "What's New" document, my fellow release managers for their encouragement and support from the start to finish of 3.6's life, the Steering Councils, the PSF Infrastructure Team, those individuals and organizations who contribute resources (money, people, time, facilities, services) to the PSF, making Python development possible. And, I suppose I should thank that git who produces the macOS packages. Thanks again to you all for making 3.6 so successful! --Ned P.S. As a reminder, with 3.6 having reached end-of-life, we no longer accept bug reports of any type against 3.6 and the 3.6 source code is now frozen. There is no longer a 3.6 branch in the GitHub cpython repository; the final state of the branch is captured in the repo as tag "3.6" and, as always, the source code for any release can be checked out using its tag; for example, the source for the final release of 3.6 can be obtained with "git checkout v3.6.15". Pro tip: if you haven't already, you may want to update your repo clones with "git fetch --tags upstream" (if you use the recommended naming convention) to get the latest tags and branches. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/CZRA7AMKWZ5AJIJM3OFYY7P24I5L2LPS/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: [RELEASE] Python 3.7.12 and 3.6.15 security updates now available
[Retransmit] Python 3.7.12 and 3.6.15, the lastest security fix rollups for Python 3.7 and Python 3.6, are now available. You can find the release files, links to the changelogs, and more information here: https://www.python.org/downloads/release/python-3712/ https://www.python.org/downloads/release/python-3615/ These releases are source code only; Windows and macOS binary installers are not provided for security fix releases. Note that Python 3.9 is now the latest feature release series of Python 3. You should consider upgrading to 3.9 as soon as practical. Get the latest release of 3.9.x here: https://www.python.org/downloads/ Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf-landing/ ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/6QXBKDVKRVHVC75UQJVWX4WC4OBGJ3PM/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: PSF hires first Developer-in-Residence (was: Re: Re: Call for resumes: Developer-in-Residence to support CPython)
On Jul 12, 2021, at 11:42, Ewa Jodlowska wrote: > Just to circle back, we have officially contracted with Łukasz Langa to be > the first CPython Developer-in-Residence! > > PSF announcement: > https://pyfound.blogspot.com/2021/07/ukasz-langa-is-inaugural-cpython.html > > We look forward to seeing all the impact that Łukasz and this role will have! I am very excited by this announcement. Thanks, Łukasz, for applying and thanks, to the PSF and the Steering Council, for securing the funding and making this wise choice. Having a developer-in-residence has the potential to make a huge positive impact on many aspects of CPython and I believe Łukasz to be one of the most qualified people for the job. I have had the privilege of working closely with him on the CPython Release Team over the past three and a half years and have come to greatly respect his technical skills, his judgement, and his obvious passion for Python. It's been a pleasure working with him so far and I look forward to his contributions in this new role over the coming months. Woot! --Ned -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/BSO5YXGBL3I4HP7HKLFBA75HNPZEB7K2/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Publish better than md5sums of Python builds?
On Mar 17, 2021, at 10:29, Victor Stinner wrote: > On Tue, Mar 16, 2021 at 9:16 PM Gregory P. Smith wrote: >> The benefit of listing the sha256 for files is that it prevents this >> question coming up again and again because md5 is old and rightfully on the >> "never use" list for many people. Even if there are situations where it is >> fine as an effective improvement over a CRC. > Would it be possible to provide multiple hashes, like MD5 *and* SHA256 > (and maybe also SHA512)? Or is there a practical problem to list > multiple hashes on a web page? Why would we need to have multiple hashes? One is sufficient. The only issue is that we are set up today to use md5 and changing to another hash takes some work, both to the web site and to how we do releases. It's not a huge amount of work but somebody(ies) need(s) to step up to do it and the only obvious reason for doing it is to stop these discussions. And that hasn't been motivation yet enough given the list of higher priority items. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/3LWFZYGAL2BLCB3P4GUW2MNCRX6K32CB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Publish better than md5sums of Python builds?
On Mar 16, 2021, at 16:16, Gregory P. Smith wrote: > The benefit of listing the sha256 for files is that it prevents this question > coming up again and again because md5 is old and rightfully on the "never > use" list for many people. Even if there are situations where it is fine as > an effective improvement over a CRC. I agree that the primary reason for making the change is to eliminate these kinds of discussions :) In fact, there has been an open issue on the python.org tracker for some time to do just that; see https://github.com/python/pythondotorg/issues/1227. It will also require co-ordination with release managers as we are the ones who populate the data, if anyone feels motivated to dig into the webside code. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/XORTTVQ23N76DK2W6NAXW5M6NW52EPQU/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.10 and 3.6.13 security updates now available
Python 3.7.10 and 3.6.13, the lastest security fix rollups for Python 3.7 and Python 3.6, are now available. You can find the release files, links to the changelogs, and more information here: https://www.python.org/downloads/release/python-3710/ https://www.python.org/downloads/release/python-3613/ These releases are source code only; Windows and macOS binary installers are not provided for security fix releases. Note that Python 3.9 is now the latest feature release series of Python 3. You should consider upgrading to 3.9 as soon as practical. Get the latest release of 3.9.x here: https://www.python.org/downloads/ Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf-landing/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/RZPY657ZXBRBKMC3H2GDO7TDG2F7UWB7/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Upcoming 3.7.10 and 3.6.13 Security Releases
We are planning to produce the next security-fix rollup releases for Python 3.7.x and 3.6.x on 2021-01-15. The most recent releases for these versions were on 2020-08-17. There has not been a lot of activity for either branch since then. Core developers: if you know of any additional security issues that should be addressed in these releases, please mark the relevant bpo issues as "release blocker" and, if possible, submit PRs for review prior to the end of 2021-01-14 AOE. Thanks! -- Ned Deily n...@python.org -- [] signature.asc Description: Message signed with OpenPGP ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/4FE3TGR73Z3P4O6XQV5W22JWI4NCDUP6/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Document the release process on devguide?
On Dec 19, 2020, at 16:55, Guido van Rossum wrote: > I take it that PEP 101 is updated whenever the recipe changes in any way? Yes, that’s the intent. And over the years, “the recipe” has become rather a multi-course banquet meal with all of the steps and systems now involved in putting out a release. I should point out that PEP 101 describes the mechanics of putting out a release. It is by no means a complete description of the role that a release manager plays in our development process. Perhaps a brief description could be written up and added to the devguide. That would be of much more value, I think. > >> On Sat, Dec 19, 2020 at 1:41 PM Ned Deily wrote: >> >> On Dec 19, 2020, at 14:57, joannah nanjekye >> wrote: >> > I got to know from Pablo that the release process is documented in a PEP >> > here: https://www.python.org/dev/peps/pep-0101/ >> > >> > I wonder if it makes sense for us to formalize this process by documenting >> > it on devguide, and adding any extra/missing information? >> >> PEP 101 is intended to be the primary documentation of the release process >> steps from the perspective of a release manager. It is not aimed at any >> other audience. There is release cycle information, aimed at developers, in >> various parts of the devguide. It could certainly be improved. Are there >> some things in particular of value to core developers that are missing or >> could use work there? > -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/RNKQ375P2PZRXQ6R2ZKMW3IYL5TD4X6F/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Document the release process on devguide?
On Dec 19, 2020, at 14:57, joannah nanjekye wrote: > I got to know from Pablo that the release process is documented in a PEP > here: https://www.python.org/dev/peps/pep-0101/ > > I wonder if it makes sense for us to formalize this process by documenting it > on devguide, and adding any extra/missing information? PEP 101 is intended to be the primary documentation of the release process steps from the perspective of a release manager. It is not aimed at any other audience. There is release cycle information, aimed at developers, in various parts of the devguide. It could certainly be improved. Are there some things in particular of value to core developers that are missing or could use work there? -- Ned Deily n...@baybryj.net -- [] signature.asc Description: Message signed with OpenPGP ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/BGNVTKM4YRHTOVRJEWZQ6DFZFGVORHF3/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Document the release process on devguide?
On Dec 19, 2020, at 16:26, joannah nanjekye wrote: > > > PEP 101 is intended to be the primary documentation of the release process > > steps from the perspective of a release manager. > > I think am talking about the documentation aimed at the release manager. And > yes whether it makes sense to move the details to devguide too. The info in PEP 101 is very specialized and we have enough trouble keeping it up-to-date in one place :) I don't see any value in trying to have it in two places. And I'm sure most people would find it tediously boring :) > Am assuming, that any core dev has the potential to be a release manager in > the future. Perhaps we could add a few sentences to the devguide about the role of the release manager, with a link to PEP 101 for those interested in getting more of a feel for the mechanics (although that is about to change somewhat anyway thanks to Pablo's work at further automating the process), and with who to contact if one is interested in becoming a release manager for a future release (today, that would be the current and past release managers). > On Sat, Dec 19, 2020 at 5:22 PM Ned Deily wrote: > On Dec 19, 2020, at 14:57, joannah nanjekye wrote: > > I got to know from Pablo that the release process is documented in a PEP > > here: https://www.python.org/dev/peps/pep-0101/ > > > > I wonder if it makes sense for us to formalize this process by documenting > > it on devguide, and adding any extra/missing information? > > PEP 101 is intended to be the primary documentation of the release process > steps from the perspective of a release manager. It is not aimed at any > other audience. There is release cycle information, aimed at developers, in > various parts of the devguide. It could certainly be improved. Are there > some things in particular of value to core developers that are missing or > could use work there? > > -- > Ned Deily > n...@python.org -- [] > > > > -- > Best, > Joannah Nanjekye > "You think you know when you learn, are more sure when you can write, even > more when you can teach, but certain when you can program." > Alan J. Perlis -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/PVIN6ISJ4AAGEQZBXPS7HLLDJQ6WVGBB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Document the release process on devguide?
On Dec 19, 2020, at 14:57, joannah nanjekye wrote: > I got to know from Pablo that the release process is documented in a PEP > here: https://www.python.org/dev/peps/pep-0101/ > > I wonder if it makes sense for us to formalize this process by documenting it > on devguide, and adding any extra/missing information? PEP 101 is intended to be the primary documentation of the release process steps from the perspective of a release manager. It is not aimed at any other audience. There is release cycle information, aimed at developers, in various parts of the devguide. It could certainly be improved. Are there some things in particular of value to core developers that are missing or could use work there? -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/DRUJNTA5JVSDEDLW3X3TP5KUMVWOWXWU/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Travis CI is no longer mandatory on Python pull requests
On Oct 19, 2020, at 14:35, Brett Cannon wrote: > On Mon, Oct 19, 2020 at 11:22 AM Ned Deily wrote: >> On Oct 19, 2020, at 13:59, Brett Cannon wrote: >> > On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman wrote: >> >> On 10/18/20 1:18 PM, Ned Deily wrote: >> >> > On Oct 18, 2020, at 15:45, Carol Willing wrote: >> >> >> We've largely moved away from Travis for Jupyter testing in favor of >> >> >> Azure pipelines and CircleCI as Travis was becoming increasingly slow >> >> >> and timing out. >> >> > >> >> > Along those lines, if we are basically going to ignore the Travis CI >> >> > results, perhaps we should consider being "good citizens" and stop >> >> > running them all together. Each PR change triggers multiple builds to >> >> > run under Travis and all that extra and useless work contributes to the >> >> > load on Travis and no doubt is not good for overall Travis >> >> > responsiveness. >> >> >> >> If we have something else set up to takes its place that's fine; >> >> otherwise, let's leave it up with the understanding >> >> that we have to check it manually for success or failure -- that's still >> >> valuable information. >> > Unfortunately, the "valuable information" lately has been whether Travis >> > is even working. >> Yes, and I still think it's unfair of us to use so much of Travis's >> resources - resources that other projects could use - when we are almost >> entirely ignoring the results. On the master branch, each time a PR is >> merged or requires a CI run, we currently start up to 5 separate Travis jobs >> (some short-circuited but still jobs). The main job. which rebuilds python >> and runs the test suite, can run for 15+ minutes. And then backports run >> some of the jobs as well. >> > Yep, if Travis has limited their free resources then we are wasting them. And > without knowing where Travis gets their electricity there's even a > potentially (very slight) ecological cost from us wasting the runs. I am with > Ned about trying on to be wasteful here just in case Travs happens to find > something in a CI run. > >> Let's just disable Travis on all branches for now until there is reason to >> believe the problems we've seen are fixed. > +1 from me. Pablo, Łukasz: any objections to disabling Travis on your branches? If not, one of us, or Ernest, can just do it. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/SSEJL7Q5NCZ7AX7VTBDQ2SDM7NL5SSF5/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Travis CI is no longer mandatory on Python pull requests
On Oct 19, 2020, at 13:59, Brett Cannon wrote: > On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman wrote: >> On 10/18/20 1:18 PM, Ned Deily wrote: >> > On Oct 18, 2020, at 15:45, Carol Willing wrote: >> >> We've largely moved away from Travis for Jupyter testing in favor of >> >> Azure pipelines and CircleCI as Travis was becoming increasingly slow and >> >> timing out. >> > >> > Along those lines, if we are basically going to ignore the Travis CI >> > results, perhaps we should consider being "good citizens" and stop running >> > them all together. Each PR change triggers multiple builds to run under >> > Travis and all that extra and useless work contributes to the load on >> > Travis and no doubt is not good for overall Travis responsiveness. >> >> If we have something else set up to takes its place that's fine; otherwise, >> let's leave it up with the understanding >> that we have to check it manually for success or failure -- that's still >> valuable information. > Unfortunately, the "valuable information" lately has been whether Travis is > even working. Yes, and I still think it's unfair of us to use so much of Travis's resources - resources that other projects could use - when we are almost entirely ignoring the results. On the master branch, each time a PR is merged or requires a CI run, we currently start up to 5 separate Travis jobs (some short-circuited but still jobs). The main job. which rebuilds python and runs the test suite, can run for 15+ minutes. And then backports run some of the jobs as well. Let's just disable Travis on all branches for now until there is reason to believe the problems we've seen are fixed. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/AYLXEBIFHWCODJSIRS3W2C2HSQKHYRHM/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Travis CI is no longer mandatory on Python pull requests
On Oct 18, 2020, at 15:45, Carol Willing wrote: > We've largely moved away from Travis for Jupyter testing in favor of Azure > pipelines and CircleCI as Travis was becoming increasingly slow and timing > out. Along those lines, if we are basically going to ignore the Travis CI results, perhaps we should consider being "good citizens" and stop running them all together. Each PR change triggers multiple builds to run under Travis and all that extra and useless work contributes to the load on Travis and no doubt is not good for overall Travis responsiveness. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/ZUHXBNZYLGRT2JKPRC5PKHULHV6JIRBZ/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Upcoming 3.7.9 and 3.6.12 Security Releases
We are planning to produce security-fix rollup releases for Python 3.7.x and 3.6.x on 2020-08-14. The most recent releases for these versions were on 2020-06-27 and 3.7.8 was the final bugfix release for 3.7. Shortly after those releases, several security issues affecting them were fixed. Because one of those fixes addresses a potential security vulnerability when using Python on Windows (https://bugs.python.org/issue29778), we are making an exception and providing updated binary installers for 3.7.9 since this first 3.7.x security release follows so soon after the final 3.7.x bugfix release. Also, starting with these releases, we plan to no longer produce release candidates for 3.7.x and 3.6.x security releases, and instead simply provide final releases, as we receive little to no feedback from security release candidates and the number of changes in each security releases is small. Core developers: if you know of any additional security issues that should be addressed in these releases, please mark the relevant bpo issues as "release blocker" and, if possible, submit PRs for review prior to the end of 2020-08-13 AOE. Thanks! -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/AS45YBRKOJQC7WB5GLHZB65HYJCNTK6A/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.8 and 3.6.11 now available - last 3.7.x bugfix release
https://discuss.python.org/t/python-3-7-8-and-3-6-11-now-available-last-3-7-x-bugfix-release/4583 -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/MBTONIO2OG46TZ5AMEUX2ATQF45LUQ4C/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.8rc1 and 3.6.11rc1 are now available for testing
Details here: https://discuss.python.org/t/python-3-7-8rc1-and-3-6-11rc1-are-now-available-for-testing/4467 https://www.python.org/downloads/release/python-378rc1/ https://www.python.org/downloads/release/python-3611rc1/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/2FY3TKOR3ULMJ26MQESAO5Y44ZCDXNE5/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x
We will be accecpting commits to the 3.7 branch until this coming Monday 06-15 23:59 AOE. At that time, 3.7 will effectively enter security-fix mode. That will also be the deadline for any additional security-fixes for release in 3.6.11. Release candidates will follow shortly thereafter. Assuming no release-blocker issues arise during the release candidate testing, 3.7.8 and 3.6.11 will release on 06-27. https://discuss.python.org/t/upcoming-cutoffs-for-3-9-3-8-3-7-and-3-6-releases-last-chance-for-3-7-bugfixes/4362 -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/EKYBL5VG6TWSTTQUNBP56VJVHDR3GRM3/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Upcoming cutoffs for 3.9, 3.8, 3.7, and 3.6 releases! Last chance for 3.7 bugfixes!
https://discuss.python.org/t/upcoming-cutoffs-for-3-9-3-8-3-7-and-3-6-releases-last-chance-for-3-7-bugfixes/4362 -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/CJWRWPFMPVYQU2SLL2OTN63RQ5JLXIEZ/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Remove accidentally created branch on cpython repo
On May 21, 2020, at 03:44, Kyle Stanley wrote: > So by my own mistake in the GitHub UI, I was looking at a previous commit for > one of my PRs (https://github.com/python/cpython/pull/19282) and misclicked > the "revert commit" button instead of "view details". Fortunately, this only > created a separate branch in the cpython repository instead of actually > reverting anything (see > https://github.com/python/cpython/tree/revert-19282-bpo40115-test_asyncio-run_in_executor_cancel), > but I'm unsure of the best way to remove the branch or if I'm even able to. You can view the active branches here: https://github.com/python/cpython/branches/active If you have permission to delete it, there will be a trashcan icon to the right of the branch. I made it go away. > Sorry about the mixup, I'm rather new to the core developer role and this is > my first time running into anything like this. No problem! We all have learning events along the way. Keep hacking! -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/HJIQD7QP3HXHADOEVGZR3LFHB3KOKID2/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: All hands on deck: the release of Python 3.9.0b1 is currently blocked
On May 18, 2020, at 11:25, Łukasz Langa wrote: > the beta 1 release of Python 3.9.0 planned for today is as of now blocked on > three issues marked as "release blocker": > > - https://bugs.python.org/issue26317 -> Resolved by a revert -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/IULS2LORRJV5SOKKUMTX6TQ44JXURSEZ/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.7 is now available
https://discuss.python.org/t/python-3-7-7-is-now-available/3682 https://www.python.org/downloads/release/python-377/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/ZLNRT7QMYUQUSGYFPWCRS2AWBAU3DDIM/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.7rc1 is now available for testing
Details here: https://discuss.python.org/t/python-3-7-7rc1-is-now-available-for-testing/3638 https://www.python.org/downloads/release/python-377rc1/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/NHPFHNHLYH5GGMP2YFHROKFF3255Q4RV/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] 3.7.7 schedule accelerated, cutoff now 2020-03-02
https://discuss.python.org/t/3-7-7-schedule-accelerated-cutoff-now-2020-03-02/3511 -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/GIVKRSVTCYOUBLWX6LPX3X2KZH4WAV4Y/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: A urlparse regression in minor version
On Feb 16, 2020, at 07:21, Antoine Pitrou wrote:
> FWIW, I agree with Senthil here. A slight behaviour change in 3.9 is
> fine, especially in an area where the "right" semantics are not
> immediately obvious. What we want to avoid is breaking behaviour
> changes in bugfix releases.
I agree totally that we don't want to break behavior in bugfix releases and I
have no problem with making breaking changes in feature releases (3.9.0) as
warranted.
My point was that, after looking at this a bit, it seems to me that making this
change does not address some of the underlying problems with the urlparse API
and that it makes things *much* worse for the many users who are understandably
expecting urlparse to sanely handle schemaless urlstrings, the most commonly
seen urls format today.
Note that we strongly imply that we sanely handle them by offering the
"scheme=" paramater to urlparse. Another example: prior to 3.7.6 and 3.8.1:
>>> urlparse("www.google.com:8080", scheme="http")
ParseResult(scheme='http', netloc='', path='www.google.com:8080', params='',
query='', fragment='')
That isn't what users would expect; what they would expect is how things work
with an explicit scheme (note the swapping of netloc and path).
>>> urlparse("https://www.google.com:8080;, scheme="http")
ParseResult(scheme='https', netloc='www.google.com:8080', path='', params='',
query='', fragment='')
But at least there is a relatively simple workaround that users have discovered
as witnessed by the requests code snippet I cited earlier: use the path field
if netloc is empty.
Now with the change in 3.8.1 and 3.7.6, the behavior is very different and
pretty useless even with an explicit scheme="http" parameter:
>>> urlparse("www.google.com:8080", scheme="http")
ParseResult(scheme='www.google.com', netloc='', path='8080', params='',
query='', fragment='')
i.e. www.google.com://8000
While that may be what strict adherence to the RFC dictates, most users aren't
going to expect or desire results like that. So while the change may fix some
cases, it's only making matters worse. What kind of workaroud do you use for
that result?
In another open issue concerning a different urlparse issue, Victor noted that
(4 months ago) "there are 124 open issues with "urllib" in their title and 12
open issues with "urlparse" in their title" and hit a bit of a dead end with a
proposed fix.
https://bugs.python.org/issue36338#msg355322
Rather than continuing this change in 3.9 introducing yet another, even more
unexpected behavior, I think we should first try to address what appears to me
to be the (a?) root cause issue: urlparse's API is not suited for parsing both
strictly RFC-compliant URLs (which are clearly not well-understood) *and*
today's schemeless URLs as have evolved over the years to become the most
commonly encountered form of URL. Users want and need both. The merged change
makes the previous situation worse, IMHO.
Le 16/02/2020 à 13:13, Senthil Kumaran a écrit :
>>
>> On Sun, Feb 16, 2020 at 2:20 AM Ned Deily > <mailto:n...@python.org>> wrote:
>>
>>
>>
>>For 3.9.0, I recommend we reconsider this change (temporarily
>>reverting it) and consider whether an API change to accommodate the
>>various use cases would be better
>>
>>
>> For 3.9. - I am ready to defend the patch even at the cost of the
>> breaking of the parsing of undefined behavior. We should keep it. The
>> patch simplifies a lot of corner cases and fixes the reported bugs. We
>> don't guarantee backward compatibility between major versions, so I
>> assume users will be careful when relying upon this undefined behavior
>> and will take corrective action on their side before upgrading to 3.9.
>>
>> We want patch releases to be backward compatible. That was the
>> user-complaint.
>>
>> Thanks,
>> Senthil
>>
>>
>>
>> ___
>> python-committers mailing list -- python-committers@python.org
>> To unsubscribe send an email to python-committers-le...@python.org
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-committers@python.org/message/SQE6TKOYZKEFGWMUHU5RCHRVWJ27TIQV/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https
[python-committers] Re: A urlparse regression in minor version
On Feb 15, 2020, at 09:00, Senthil Kumaran wrote:
> As we have to a decision here, my vote is to revert the patch in 3.8.2 and
> 3.7.7
> I have gone back-and-forth with this thinking, and it seems revert might
> address some definite complaints we have got.
> The problem is contained to single version, and users can upgrade to the next
> one.
> On Fri, Feb 14, 2020 at 8:14 AM Łukasz Langa wrote:
>> Ned, what are you doing with this for 3.7.7? Reverting?
Ugh!
As others have noted, urlparse is a big can of worms. I am certainly not a
subject expert but, from some investigation and thinking about it, it seems to
me that we kinda brought this on ourselves by allowing the scheme part (e.g.
"https:" or "ftp:" or "any-old-scheme:" etc) of the urlstring parameter to be
optional:
urllib.parse.urlparse(urlstring, scheme='', allow_fragments=True)
therby introducing the ambiguity of whether a string like "localhost:80"
denotes a relative url with a user-defined scheme of "localhost" and a path of
"80" (as it now does with the changes for bpo-27657 introduced in 3.8.1 and
3.7.6):
>>> urlparse("localhost:80")
ParseResult(scheme='localhost', netloc='', path='80', params='', query='',
fragment='')
or denotes a relative url with no scheme and a path of "localhost:80" (as
happened in previous releases):
>>> urlparse("localhost:80")
ParseResult(scheme='', netloc='', path='localhost:80', params='', query='',
fragment='')
With an explicit scheme, in either case you get what you would expect - an
absolute url:
>>> urlparse("http://localhost:80;)
ParseResult(scheme='http', netloc='localhost:80', path='', params='', query='',
fragment='')
AFAICT the intent of the original RFCs was to require an explicit scheme in a
urlstring, thus avoiding any ambiguity. But the now universal practice of web
browsers supplying a default http: or https: scheme for (partial) urls typed
into a location bar has understandably changed user expectations to often be
that schemes are optional when the scheme is clear in context.
So it seems to me that there is no one obviously correct behavior here.
Judging from the comments and the reports of broken packages, many users are
clearly used to using urlparse with schemeless urlstrings even if they aren't
truly conformant URLs and even with the at first glance unintuitive way they
were parsed by urlparse; for example, there is this snippet in the third-party
requests package:
# urlparse is a finicky beast, and sometimes decides that there isn't a
# netloc present. Assume that it's being over-cautious, and switch netloc
# and path if urlparse decided there was no netloc.
if not netloc:
netloc, path = path, netloc
OTOH, there are also undoubtedly users who want a urlparser that more strictly
parses schemeless URLs, which is now the behavior as of 3.8.1 and 3.7.6, again,
even if the new behavior is also unintuitive.
I don't see how we can satisfy both use cases without changing the API somehow.
And there may be other use cases.
The good news is that, AFAICT from a quick survey, the change didn't affect
urllib.urlopen or thrid-party urllib3 or requests. But from the "me-toos" on
the bpo issue and the PR, it's clear that we broke stuff downstream and it
seems that most of those users are waiting for a resolution from us and likely
would prefer to stick to the previous behavior.
So my take is that we should revert the 3.7 changes (bpo-27657 / PR 16837 /
82b5f6b16e051f8a2ac6e87ba86b082fa1c4a77f ). Senthil, please go ahead and do so
for the 3.7 branch. Thanks!
While it's not my call, I think we should also revert for 3.8.2.
For 3.9.0, I recommend we reconsider this change (temporarily reverting it) and
consider whether an API change to accommodate the various use cases would be
better; perhaps something like adding a new parameter to urlparse to indicate
whether urlstrings should be parsed like webbrowser "urls" (and defining
exactly what that means) and also review the many remaining open urlparse bpo
issues to look for commonalities. (Perhaps that could be a post-3.9 GsoC
project?)
Thoughts?
In any case, ugh!
--
Ned Deily
n...@python.org -- []
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/LSQG3M7G4WB7LNOSBU52AMAKB7LBD7WT/
Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: getting old branches/releases
On Feb 11, 2020, at 19:26, Ethan Furman wrote: > On 02/11/2020 04:04 PM, Mariatta wrote: >> On Tue, Feb 11, 2020 at 3:49 PM Ethan Furman wrote: > >>> I'm trying to get the 3.3 and 3.4 branches so I can check my libraries' >>> compatibility with older versions, but I do not see those branches as being >>> available: >>> How can I get those? >> 3.3 and 3.4 existed before the migration from GitHub, so we don't have the >> branches. >> They are in the repo as git tags. >> Try: >> # list all git tags matching v.3.3 >> git tag -l 'v3.3*' >> # checkout the v.3.3.0 tag to a local branch >> git checkout tags/v.3.3.0 -b my-own-3.3.0-branch > > Nice! Many thanks! It's a bit simpler than that. You don't need to specify `tags/` when referencing tags. git checkout v3.3.7 # for final 3.3 release (in detached HEAD mode) git checkout v3.3.7 -b v3.3.7 # to also create a local branch git checkout 3.3 -b 3.3 # for the final state of the 3.3 branch https://git-scm.com/book/en/v2/Git-Basics-Tagging -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/SJJ6JQNNK3ARPUWYF45POSTIR5OJH7TI/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.6rc1 and 3.6.10rc1 are now available for testing
Details here: https://discuss.python.org/t/python-3-7-6rc1-and-3-6-10rc1-are-now-available-for-testing/2835 https://www.python.org/downloads/release/python-376rc1/ https://www.python.org/downloads/release/python-3610rc1/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/XKTDJJJSNREGG5CYSJW26ZTVBB7BHRFI/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] 3.8.1rc1, 3.7.6rc1, and 3.6.10rc1 cutoffs ahead
It's that time for another reminder: code cutoffs for the last scheduled releases of 2019 are coming up soon. They are a little earlier than usual to try to avoid the end-of-December rush of various holidays. Łukasz will have more details forthcoming about **3.8.1rc1**. For the **3.7 branch**, the cutoff for **3.7.6rc1** is scheduled for this coming Monday (2019-12-09) by the end of day AOE. I have also now scheduled the cutoff for the next cumulative security source release for the **3.6 branch**, **3.6.10rc1**, for Monday as well. Please review open issues and ensure that any that you believe need to be addressed in any of these releases are either resolved or marked as a **release blocker**. Any assistance you can provide in helping resolve issues will be greatly appreciated. As usual, following the rc1 cutoff, changes merged to the 3.7 branch will be released in **3.7.7** three months from now unless you mark the issue as a release blocker prior to **3.7.6 final**, planned for release on **2019-12-16**, and explain why the change should be cherry-picked into the final release. And as always, any proposed changes for the 3.6 branch need to meet the criteria for security branches and require release manager approval to merge. Thanks for your continued efforts! 3.8 release PEP: https://www.python.org/dev/peps/pep-0569/ 3.7 release PEP: https://www.python.org/dev/peps/pep-0537/ 3.6 release PEP: https://www.python.org/dev/peps/pep-0494/ Security branch criteria: https://devguide.python.org/devcycle/#security-branches -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/GYGZGI5VHSRX7U5JXS7MDRQ6LEQGFTLM/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.5 is now available
Python 3.7.5 is now available, the next maintenance release of Python 3.7. You can find the release files, a link to the changelog, and more information here: https://www.python.org/downloads/release/python-375/ Note that the next feature release of Python 3, Python 3.8.0, is also now available. Python 3.8 contains many new features and optimizations. You should consider upgrading to it. We plan to continue regular bugfix releases of Python 3.7.x through mid-year 2020 and provide security fixes for it until mid-year 2023. More details are available in PEP 537, the Python 3.7 Release Schedule (https://www.python.org/dev/peps/pep-0537/). Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q5OUNSBNIQTMVOUXYKBOPEX6NSBKNKEE/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.5rc1 is now available for testing
Python 3.7.5rc1 is now available for testing. 3.7.5rc1 is the release preview of the next maintenance release of Python 3.7, the latest feature release of Python. Assuming no critical problems are found prior to 2019-10-14, no code changes are planned between now and the final release. This release candidate is intended to give you the opportunity to test the new security and bug fixes in 3.7.5. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that this is a preview release and, thus, its use is not recommended for production environments. You can find the release files, a link to the changelog, and more information here: https://www.python.org/downloads/release/python-375rc1/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/JE56V6R6LJPCHOVX5BW7QOLJXA6GEQ73/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: [Python-Dev] 3.7.5rc1 release blocked (Re: 3.7.5rc1 cutoff ahead)
2019-09-28 Update: we are still awaiting resolution of some release blockers but I am hopeful we will be unblocked very shortly. I have rescheduled the cutoff for 3.7.5rc1 for this coming Monday (2019-09-30) and, assuming no showstopper problems are identified in the release candidate, 3.7.5 final will follow on 2019-10-14. **Please note** that the next few weeks are **very** important ones for Python releases. Besides 3.7.5, important code cutoffs and release candidate testing periods are coming up for 3.8.0, 3.5.8, and 2.7.17. Please keep an eye out for release blockers, test failures, and any other issues that could affect the quality of releases and please open or update issues on b.p.o, adding **release blocker** priority as necessary to make sure the release managers are aware of them. Thanks! https://www.python.org/dev/peps/pep-0537/ https://www.python.org/dev/peps/pep-0569/ https://www.python.org/dev/peps/pep-0478/ https://www.python.org/dev/peps/pep-0373/ https://bugs.python.org On Sep 17, 2019, at 19:26, Ned Deily wrote: > 2019-09-17 Update: as of the scheduled cutoff time earlier today, we had two > recently identified release blocker issues open. Thanks to Andrew and Yury, > one of them is now resolved with code (bpo-38013). The other (bpo-30458 and > bpo-36274) remains unresolved at this point. Because the issue(s) involve an > apparent regression introduced in a fix for a security issue in 3.7.4, a > regression that has affected at least one third-party project (and has the > potential to affect releases from other branches), I think we should resolve > this now. A number of core devs have been involved in these two issues most > recently Jason. I'm am going to delay tagging the release for at least a > day. Anything you can do to help resolve this one, especially if you have > already been involved with it, would be greatly appreciated. > > https://bugs.python.org/issue30458 > [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of > CVE-2016-5699) > > https://bugs.python.org/issue36274 > http.client cannot send non-ASCII request lines > > > On Sep 9, 2019, at 07:10, Ned Deily wrote: >> https://discuss.python.org/t/3-7-5rc1-cutoff-ahead/2288 >> >> A reminder: it is time for the next quarterly maintenance release of Python >> 3.7. The cutoff for **3.7.5rc1** is scheduled for this coming Monday >> (2019-09-16) by the end of day AOE. Please review open issues and ensure >> that any that you believe need to be addressed in 3.7.5 are either resolved >> or marked as a **release blocker**. Any assistance you can provide in >> helping resolve issues will be greatly appreciated. Following the rc1 >> cutoff, changes merged to the 3.7 branch will be released in 3.7.6 three >> months from now unless you mark the issue as a release blocker prior to >> **3.7.5 final**, planned for release on **2019-09-30** and explain why the >> change should be cherry-picked into the final release. >> >> Thanks to everyone who has been helping to ensure the continued success of >> Python 3.7! Our users truly appreciate it and are showing their confidence >> in us by the rapid adoption of these latest releases. >> >> P.S. A number of core developers are participating in this year's core >> developer sprint taking place this week in London. So it is a good time to >> catch many of us in the same place at the same time (and British Summer >> Time, at that). >> >> https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/2HAJ5GZ3K6CR4YREDIR4IZWM4EW4B3LQ/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] 3.7.5rc1 release blocked (Re: [Python-Dev] 3.7.5rc1 cutoff ahead)
2019-09-17 Update: as of the scheduled cutoff time earlier today, we had two recently identified release blocker issues open. Thanks to Andrew and Yury, one of them is now resolved with code (bpo-38013). The other (bpo-30458 and bpo-36274) remains unresolved at this point. Because the issue(s) involve an apparent regression introduced in a fix for a security issue in 3.7.4, a regression that has affected at least one third-party project (and has the potential to affect releases from other branches), I think we should resolve this now. A number of core devs have been involved in these two issues most recently Jason. I'm am going to delay tagging the release for at least a day. Anything you can do to help resolve this one, especially if you have already been involved with it, would be greatly appreciated. https://bugs.python.org/issue30458 [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699) https://bugs.python.org/issue36274 http.client cannot send non-ASCII request lines On Sep 9, 2019, at 07:10, Ned Deily wrote: > https://discuss.python.org/t/3-7-5rc1-cutoff-ahead/2288 > > A reminder: it is time for the next quarterly maintenance release of Python > 3.7. The cutoff for **3.7.5rc1** is scheduled for this coming Monday > (2019-09-16) by the end of day AOE. Please review open issues and ensure that > any that you believe need to be addressed in 3.7.5 are either resolved or > marked as a **release blocker**. Any assistance you can provide in helping > resolve issues will be greatly appreciated. Following the rc1 cutoff, > changes merged to the 3.7 branch will be released in 3.7.6 three months from > now unless you mark the issue as a release blocker prior to **3.7.5 final**, > planned for release on **2019-09-30** and explain why the change should be > cherry-picked into the final release. > > Thanks to everyone who has been helping to ensure the continued success of > Python 3.7! Our users truly appreciate it and are showing their confidence in > us by the rapid adoption of these latest releases. > > P.S. A number of core developers are participating in this year's core > developer sprint taking place this week in London. So it is a good time to > catch many of us in the same place at the same time (and British Summer Time, > at that). > > https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/V3R3HSUIU3ZOXM776BSS4OKEU3G2RJMG/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] 3.7.5rc1 cutoff ahead
https://discuss.python.org/t/3-7-5rc1-cutoff-ahead/2288 A reminder: it is time for the next quarterly maintenance release of Python 3.7. The cutoff for **3.7.5rc1** is scheduled for this coming Monday (2019-09-16) by the end of day AOE. Please review open issues and ensure that any that you believe need to be addressed in 3.7.5 are either resolved or marked as a **release blocker**. Any assistance you can provide in helping resolve issues will be greatly appreciated. Following the rc1 cutoff, changes merged to the 3.7 branch will be released in 3.7.6 three months from now unless you mark the issue as a release blocker prior to **3.7.5 final**, planned for release on **2019-09-30** and explain why the change should be cherry-picked into the final release. Thanks to everyone who has been helping to ensure the continued success of Python 3.7! Our users truly appreciate it and are showing their confidence in us by the rapid adoption of these latest releases. P.S. A number of core developers are participating in this year's core developer sprint taking place this week in London. So it is a good time to catch many of us in the same place at the same time (and British Summer Time, at that). https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/JFLLZSZWFCX43P5MD2WSNCV3WQFCMIMH/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.4 is now available
Python 3.7.4 is now available. 3.7.4 is the next maintenance release of Python 3.7, the latest feature release of Python. You can find the release files, a link to the changelog, and more information here: https://www.python.org/downloads/release/python-374/ See the "What’s New In Python 3.7" document for more information about the many new features and optimizations included in the 3.7 series. Detailed information about the changes made in 3.7.4 can be found in its change log: https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-4-final https://docs.python.org/3.7/whatsnew/3.7.html Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation: https://www.python.org/psf/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/RYEXOIFHMEM4F2YQZAEVWWIQ3U2KUZ7M/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.6.9 security-fix release is now available
Python 3.6.9 is now available. 3.6.9 is the first security-only-fix release of Python 3.6. Python 3.6 has now entered the security fix phase of its life cycle. Only security-related issues are accepted and addressed during this phase. We plan to provide security fixes for Python 3.6 as needed through 2021, five years following its initial release. Security fix releases are produced periodically as needed and only provided in source code form; binary installers are not provided. We urge you to consider upgrading to the latest release of Python 3.7, the current fully-supported version. You can find the release files, a link to the changelog, and more information here: https://www.python.org/downloads/release/python-369/ https://www.python.org/downloads/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/2RNGWKRLOI5DJYNAJ75B2WH6VOHTMPSE/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.4rc2 is now available for testing
Python 3.7.4rc2 is now available. 3.7.4rc2 is the second release preview of the next maintenance release of Python 3.7, the latest feature release of Python. Assuming no further critical problems are found prior to 2019-07-08, no code changes are planned between this release candidate and the final release. The release candidate is intended to give you the opportunity to test the new security and bug fixes in 3.7.4. Because of the small number of changes between rc1, the original release preview, and rc2, we are planning on an abbreviated exposure cycle so we can get the final release to you as soon as possible. We strongly encourage you to test your projects and report issues found to https://bugs.python.org/ as soon as possible. Please keep in mind that this is a preview release and, thus, is not recommended for production environments. You can find the release files, a link to the changelog, and more information here: https://www.python.org/downloads/release/python-374rc2/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/OFNLRRAT4WIILKBKCNMI2YQ5HSS5N4ES/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: [Python-Committers] [RELEASE] Python 3.7.4rc2 is now available for testing
As you've probably seen already, 3.7.4rc2 is now available. We were on target to get 3.7.4 final out last Friday as scheduled but, fortunately for quality, a few last-minute issues, primarily with TLS 1.3 support, were identified shortly before we were about to produce the release. Because the OpenSSL project is helping to push TLS 1.3 with OpenSSL 1.1.1 and is planning to end support of 1.1.0 in a few months which we had been supplying in our Windows and macOS binary installers, an important objective of 3.7.4 is to migrate to 1.1.1. It's no secret that the transition to TLS 1.3 in the industry has not been totally without problems so it's not surprising to find a few in our support of it. Thanks to Christian Heimes for following by on the issues as he wrote about earlier. We decided that, because there are non-trivial changes since rc1, we really needed to do a second release candidate. But because we are so late with 3.7.4 and because of the press of other committments like EuroPython, we are tryting to stick to a *very* brief exposure period. Assuming nothing shows up by next Monday, we will plan to release then. Any exposure and testing you can arrange for rc2 would be greatly appreciated, particularly testing of TLS 1.3 and secure networking in general. As always, please mark any issues you think may impact the release as a "release blocker" in bugs.python.org. Also, keep merging fixes to the 3.7 branch as warranted; they will end up in 3.7.5, the next maintenance release, unless they are judged to be release blockers in which case we will cherry-pick them into 3.7.4 (although it would be *really* great to not have any of those!). As always, thanks for all you do to help make Python available to the world! P.S. Now that we are over this hump, expect to see 3.8.0b2 real soon now. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/ASYHO5ZQWLHNI7I64K6SERU5MYCB4FEH/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] 3.7.4 final delayed [Was: Python 3.7.4rc1 (and 3.6.9rc1) cutoffs ahead, now set for 2019-06-17]
On Jun 6, 2019, at 01:43, Ned Deily wrote: > > https://discuss.python.org/t/python-3-7-4rc1-and-3-6-9rc1-cutoffs-ahead-now-set-for-2019-06-17/1824 > [...] > Following the rc1 cutoff, changes merged to the > 3.7 branch will be released in 3.7.5 three months from now unless you > mark the issue as a release blocker prior to **3.7.4 final**, planned for > release on **2019-06-28**, and explain why the change should be > cherry-picked into the final release. Update: 3.7.4 final is delayed at least a few days A few last minute release blocker issues were identified shortly before 3.7.4 final was about to tagged as planned on 2019-06-28, in particular, a couple of TLS 1.3 issues which are of particular importance since we are migrating Windows and macOS installers to OpenSSL 1.1.1 with this release. We are now on hold awaiting resolutions for the remaining items and then we will need to decide whether another release candidate is needed. I am hopeful we will be able to proceed by Monday 2019-07-01; I will keep you updated. And thanks for your help! -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/VWI7MZLZ5CD5RRQN6QMMUZGDP4L4XP2K/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Blurb question: error in Misc/NEWS.d/3.8.0b1.rst
On Jun 19, 2019, at 21:00, Eric V. Smith wrote: > I made a typo in a blurb file that's been incorporated into > Misc/NEWS.d/3.8.0b1.rst. I referenced an incorrect bpo number. How do I go > about fixing it? Can I just modify that .rst file, or is there some other > process I need to perform? The individual blurb files are consolidated into a single release file by release managers during a release's manufacturing steps. Once the release is out the door and the release's consolidated file appears in the repo (in this case, 3.8.0b1.rst), you can merge changes to it. Prior to the release cutoff, you can modify the individual file in Misc/NEWS.d/next. Don't forget to make similar changes as necessary to any backported PRs! -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/XHMKZW4DAA4ZPBZOZVZYTLIMQNTTAACN/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.4rc1 and 3.6.9rc1 are now available
Python 3.7.4rc1 and 3.6.9rc1 are now available. 3.7.4rc1 is the release preview of the next maintenance release of Python 3.7, the latest feature release of Python. 3.6.9rc1 is the release preview of the first security-fix release of Python 3.6. Assuming no critical problems are found prior to 2019-06-28, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.4 and security fixes in 3.6.9. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. You can find the release files, a link to their changelogs, and more information here: https://www.python.org/downloads/release/python-374rc1/ https://www.python.org/downloads/release/python-369rc1/ -- Ned Deily n...@python.org -- [] ___ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/7R7C7YLPXJ6AR3M2XZA7IKSHZ2SQFBYG/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Python 3.7.4rc1 (and 3.6.9rc1) cutoffs ahead, now set for 2019-06-17
https://discuss.python.org/t/python-3-7-4rc1-and-3-6-9rc1-cutoffs-ahead-now-set-for-2019-06-17/1824 A reminder: it is time for the next quarterly maintenance release of Python 3.7. The cutoff for **3.7.4rc1** had been scheduled for this coming Monday (2019-06-10) but many of us have been focused on feature code off for 3.8.0, which just took place a few days ago (yay!). So, to give us all a bit more time to attend to 3.7.x matters, I have moved the code cutoff a week, to **Monday 2019-06-17** by the end of day AOE. Please review open issues and ensure that any that you believe need to be addressed in 3.7.4 are either resolved or marked as a **release blocker**. Any assistance you can provide in helping resolve issues will be greatly appreciated! Following the rc1 cutoff, changes merged to the 3.7 branch will be released in 3.7.5 three months from now unless you mark the issue as a release blocker prior to **3.7.4 final**, planned for release on **2019-06-28**, and explain why the change should be cherry-picked into the final release. I am also scheduling for the same dates the rc1 and final releases of Python **3.6.9**, which is the first 3.6 security-fix-only source release since its final bugfix release, 3.6.8, six months ago. If there are any open security issues that you feel should be backported to 3.6, please get them in before its cutoff on **2019-06-17** AoE. Thanks to everyone who has been helping to ensure the continued success of Python 3.6 and 3.7! Our users truly appreciate it and are showing their confidence in us by the rapid adoption of these latest releases. Onward! P.S. I have recently updated the 3.7.x release schedule in PEP 537 to show tentative release dates for the rest of 3.7's bugfix phase. Like with 3.6, we plan to continue having 3.7.x bugfix releases every three months until 2020-06-27, two years after the initial release of 3.7.0. At that point, 3.7.x will enter its security-fix-only phase for an additional three years. https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@python.org -- [] python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.7.3 is now available
https://blog.python.org/2019/03/python-373-is-now-available.html Python 3.7.3 is now available. Python 3.7.3 is the next maintenance release of Python 3.7, the latest feature release of Python. You can find Python 3.7.3 here: https://www.python.org/downloads/release/python-373/ See the What’s New In Python 3.7 document for more information about the many new features and optimizations included in the 3.7 series. Detailed information about the changes made in 3.7.3 can be found in its change log. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://docs.python.org/3.7/whatsnew/3.7.html https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-3-final https://www.python.org/psf/ -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.3rc1 is now available for testing.
Python 3.7.3rc1 is now available for testing. 3.7.3rc1 is the release preview of the next maintenance release of Python 3.7, the latest feature release of Python. Assuming no critical problems are found prior to 2019-03-25, no code changes are planned between now and the final release. This release candidate is intended to give you the opportunity to test the new security and bug fixes in 3.7.3. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that this is a preview release and, thus, its use is not recommended for production environments. You can find the release files, a link to the changelog, and more information here: https://www.python.org/downloads/release/python-373rc1/ -- Ned Deily n...@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/
[python-committers] 3.7.3rc1 cutoff ahead
https://discuss.python.org/t/3-7-3rc1-cutoff-ahead/995 A reminder: it is time for the next quarterly maintenance release of Python 3.7. The cutoff for 3.7.3rc1 is scheduled for Monday 2019-03-11 by the end of the day AOE. Please review open issues and ensure that any that you believe need to be addressed in 3.7.3 are either resolved or marked as a release blocker. And any assistance you can provide in helping resolve issues will be greatly appreciated! Following the rc1 cutoff, changes merged to the 3.7 branch will be released in 3.7.4 three months from now unless you mark the issue as a release blocker prior to 3.7.3 final, planned for 2019-03-25, and explain why the change should be cherry-picked into the final release. https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@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/
Re: [python-committers] Can we choose between mailing list and discuss.python.org?
On Feb 12, 2019, at 20:36, Barry Warsaw wrote: >> On Feb 12, 2019, at 13:59, Antoine Pitrou wrote: >> I know I can browse easily through a 161-message mailing-list or >> newsgroup thread using a traditional threaded view, read what I want, >> come back later to read the rest, etc. But Discourse's linear >> presentation pretty much kills that ability. It doesn't even allow >> *seeing* the structure of the discussion. > That’s pretty much my same, biggest gripe about long GitHub issues and PRs. ;) But you realize that this a feature, not a bug? :) https://blog.codinghorror.com/web-discussions-flat-by-design/ -- Ned Deily n...@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/
Re: [python-committers] "bedevere/news — News entry file name incorrectly formatted"
On Jan 21, 2019, at 15:07, Antoine Pitrou wrote: > A potential explanation: the original PR title was formatted as > "bpo-XX : ..." (note the space before the colon). I fixed it to > "bpo-X: ..." but the bot didn't run again. Perhaps that's related? Possibly, if you modified the news entry while the other CI checks were still running? I guess you could force the whole CI process to run again by closing and re-opening the PR. Or a release manager could override it with an appropriate bribe. -- Ned Deily n...@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/
Re: [python-committers] "bedevere/news — News entry file name incorrectly formatted"
On Jan 21, 2019, at 14:44, Antoine Pitrou wrote: > The NEWS file check failed in a weird way here: > https://github.com/python/cpython/pull/11531 > > Could someone take a look and find out the reason for failure? I'm mystified. The blurb news file in the PR looks fine and produces a valid changelog with a local docs build. I don't see anything odd on the GitHub end of things. Perhaps Mariatta can take a look at the Bevedere end? -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.2 and 3.6.8 are now available
https://blog.python.org/2018/12/python-372-and-368-are-now-available.html Python 3.7.2 and 3.6.8 are now available. Python 3.7.2 is the next maintenance release of Python 3.7, the latest feature release of Python. You can find Python 3.7.2 here: https://www.python.org/downloads/release/python-372/ See the What’s New In Python 3.7 document for more information about the many new features and optimizations included in the 3.7 series. Detailed information about the changes made in 3.7.2 can be found in its change log. We are also happy to announce the availability of Python 3.6.8: https://www.python.org/downloads/release/python-368/ Python 3.6.8 is planned to be the last bugfix release of Python 3.6. Per our support policy, we plan to provide security fixes for Python 3.6 as needed through 2021, five years following its initial release. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://docs.python.org/3.7/whatsnew/3.7.html https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-2-final https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-8-final https://www.python.org/psf/ -- Ned Deily n...@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/
Re: [python-committers] Extending 3.6 [was: 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!]
On Dec 19, 2018, at 04:14, Serhiy Storchaka wrote: > Can we revise our policy and prolong the bug fixing mode for 3.6? 3.6 is > the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several > important syntax features it can be a minimal required version for long > time. We could but we are not going to now for multiple reasons. > I merged several PRs before releasing 3.6.8rc1, but there are still less > trivial bugfix PRs which need more time for reviewing, and there are bugs > for which no PR is created yet. There is also a number of documentation > PRs. I propose to allow backporting bugfixes to 3.6 if they do not need > excessive work, but stop to fix 3.6 only bugs. After migrating to GitHab, > backporting became less painful, most of backports to 3.6 can be done > automatically from master or from 3.7. There are always going to be bugs that remain unfixed when a release branch moves from bugfix mode to security-fix only mode. That has been true for all previous Python branches. So what, if anything, is different about 3.6? I see two possibly significant differences: - 3.6 is clearly the most widely adopted Python 3 release to date and is likely to be in the field longer than previous 3.x releases. - As Serhiy notes, it is now easier for core developers to port changes to other branches. What hasn't changed in 3.6? - We have had many discussions about Python 3 release cycles in a number of different venues, e.g. in the mailing lists, at PyCon Language Summits, at Core Developer Sprints, etc. People have made many different arguments for how long a release cycle should be and how long we should maintain a release branch. In the end, we made a plan that started 3.5 years ago, one that we have been following and one that we have set expectations for us and for our downstream users, big and small. - While the act of backporting a fix is obviously an important part of producing a maintenance release, it is not the only part. As Victor noted, there is the CI infrastructure that needs to be monitored and maintained, primarily our CI platforms and buildbots. And Victor knows better than almost anyone that those things require constant attention, even if the number of supported platforms and level of activity were somehow reduced. This activity is exhausting and has led to more than one case of core developer (near-)burnout. Besides that, there are less visible but very important activities that are part of our release process: monitoring of release activity, manufacturing releases, encouraging and monitoring downstream testing by third-party developers, distributors, and users, etc. So, extending the bugfix support window of a release affects and is asking for significant commitments from core developers, release teams, infrastructure support, third-party users and distributors. It is not something to be taken lightly - especially when most of the people involved in these activities are volunteers and largely unpaid. On Dec 19, 2018, at 13:24, Gregory P. Smith wrote: > Ned - and any release manager in this situation in the future - has a > default valid answer to this request: No. > > If we're ever going to do an "EL" or "LTS" Python, that should be decided > and agreed upon *long before the end of its existing planned maintenance > cycle* instead of right as it is ending. Ideally before the first x.y.0 > with agreement of the release manager. Though it'd likely be fine to have > that conversation about 3.7 as it is still young, the RM gets final say > into if or how that would work. > > I know that I won't be bothering with 3.6 backport/review work myself > anymore outside of special circumstances. I think Greg says it better than I could - thanks! We have had several years to discuss this. There have been a number of proposals but none have resulted in a reviewed, approved PEP. Literally one day before the final bugfix release is not the time to make such a big change in our plans. It certainly is legitimate and necessary to consider such changes in the future when we have our new governance process in place and, at that time, we can consider revising our plans for 3.7 which is still relatively early in its bugfix phase. And, if there were concrete proposals with funding sources for co-ordinating extended support for 3.6, we should consider them. I think a reasonable target is to have a final discussion and decision made by the next Language Summit upcoming in May; there is plenty of work to be done before then, i.e. start new or revise exiting PEPs. But in the absence of any of that at the moment, it would be a disservice to all to consider making such major changes and commitments now. And it's not something that I as release manager or any of us individually as core developers can or should do. --Ned P.S. Thanks for bringing this up,
[python-committers] [RELEASE] Python 3.7.2rc1 and 3.6.8rc1 now available for testing
https://blog.python.org/2018/12/python-372rc1-and-368rc1-now-available.html Python 3.7.2rc1 and 3.6.8rc1 are now available. 3.7.2rc1 is the release preview of the next maintenance release of Python 3.7, the latest feature release of Python. 3.6.8rc1 is the release preview of the next and last maintenance release of Python 3.6, the previous feature release of Python. Assuming no critical problems are found prior to 2018-12-20, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.2 and 3.6.8. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. You can find these releases and more information here: https://www.python.org/downloads/release/python-372rc1/ https://www.python.org/downloads/release/python-368rc1/ -- Ned Deily n...@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/
Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
https://discuss.python.org/t/3-7-2rc1-and-3-6-8rc1-cutoffs-ahead-last-3-6-x-bugfix-release/510/3?u=nad OK, thanks to a lot of hard work by many of you, I think we are ready to start the manufacturing of **3.7.2rc1** and **3.6.8rc1**. For the **3.7 branch**, as usual feel free to continue to merge the usual changes appropriate for a `bugfix` branch; unless otherwise marked and agreed on as a **release blocker** for 3.7.2 final, any new 3.7 merges will be released in 3.7.3. For the **3.6 branch**, as announced 3.6.8 is planned to be **the last bugfix release** for the 3.6 series; future 3.6.x releases will be as needed and contain **only security fixes** and source only. Of course, if any release blocker regressions show up after 3.6.8rc1, we will consider merging fixes for them. This means that, **as of now, the 3.6 branch is no longer open to normal bugfixes**, only security fixes and release blocker regressions fixes and only with the approval of the release manager. Therefore, as we have done with previous branches moving to security-fix mode, merges to the 3.6 branch on the `cpython` GitHub repo are now restricted to the release managers. If you feel a change to 3.6 is needed either because it is a **release blocker regression** in 3.6.8 or because it is a **security issue**, please ensure there is a bpo issue describing the problem, mark it as **release blocker** priority, and submit the necessary PR. At some point, on or after the 3.6.8 release, we will be going through the open 3.6 PRs, open PRs with the `needs backport to 3.6` label, and bpo issues marked for 3.6 and updating or closing them as needed. **Please do not mark new PRs with the** `needs backport to 3.6` **label** unless you feel the proposed change meets one of the criteria above. Thanks for your help! -- Ned Deily n...@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/
Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
On Dec 4, 2018, at 03:42, Ned Deily wrote: > https://discuss.python.org/t/3-7-2rc1-and-3-6-8rc1-cutoffs-ahead-last-3-6-x-bugfix-release/510 An update: as of the planned Friday cutoff, we still had a few open issues. Since 3.6.8 is the last planned bugfix for the 3.6 branch, I would like to make sure we leave it in as good a state as possible before it moves to security-fix-only mode. Also, the Windows App Store support for 3.7.x that Steve D has been working on is in final review and it would be great to have that in the release candidate. So I'm going to extend the cutoff for 3.7.2rc1 and 3.6.8rc1 until **Monday, 12-10, end of day (AOE**), in other words **about 30 hours from now**. Thanks for all your efforts so far! > We're reaching the end of the year and it's time for another pair of Python 3 > maintenance releases, 3.7.2 and 3.6.8, before we ring out 2018. Since there > are still some open release blocker issues and I haven't been bugging you > about them, I've moved the code cutoff for the release candidates to this > coming Friday, 12-07, by the end of the day (AOE). That gives us all another > 4 days to review open issues and PRs. Please give highest attention to any > release blockers you have been shepherding or reviewing. Thanks! > > A reminder: as previously announced, 3.6.8 is planned to be the last bugfix > release of the 3.6 series. Python 3.6.0 was released on 2016-12-23, so by > the time 3.6.8 is released, 3.6.x will have been in bugfix mode almost > exactly 2 years. When a new feature release is made and enters "bugfix" > mode, our policy has long been to continue to maintain the previous bugfix > branch for at least one more release and then move that branch to "security > fix only" mode. 3.7.0 (and 3.6.6) was released nearly six months ago and, > with the release of 3.6.8, there will have been two additional 3.6.x bugfix > releases since then. So, barring any showstopper issues that might arise, > the upcoming 3.6.8rc1 is your last chance to make bugfix changes for 3.6.x. > Following the successful release of 3.6.8, only security fixes will be > accepted for the 3.6 branch and future 3.6.x releases will be source-only and > scheduled as needed; no further binary installers will be produced for 3.6. > Refer to the Dev Guid e > sections and release PEPs linked below for more information. > > > https://devguide.python.org/devcycle/ > https://devguide.python.org/#branchstatus > https://www.python.org/dev/peps/pep-0494/ > https://www.python.org/dev/peps/pep-0537/ > > -- > Ned Deily > n...@python.org -- [] > > ___ > Python-Dev mailing list > python-...@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/nad%40python.org -- Ned Deily n...@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/
[python-committers] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
https://discuss.python.org/t/3-7-2rc1-and-3-6-8rc1-cutoffs-ahead-last-3-6-x-bugfix-release/510 We're reaching the end of the year and it's time for another pair of Python 3 maintenance releases, 3.7.2 and 3.6.8, before we ring out 2018. Since there are still some open release blocker issues and I haven't been bugging you about them, I've moved the code cutoff for the release candidates to this coming Friday, 12-07, by the end of the day (AOE). That gives us all another 4 days to review open issues and PRs. Please give highest attention to any release blockers you have been shepherding or reviewing. Thanks! A reminder: as previously announced, 3.6.8 is planned to be the last bugfix release of the 3.6 series. Python 3.6.0 was released on 2016-12-23, so by the time 3.6.8 is released, 3.6.x will have been in bugfix mode almost exactly 2 years. When a new feature release is made and enters "bugfix" mode, our policy has long been to continue to maintain the previous bugfix branch for at least one more release and then move that branch to "security fix only" mode. 3.7.0 (and 3.6.6) was released nearly six months ago and, with the release of 3.6.8, there will have been two additional 3.6.x bugfix releases since then. So, barring any showstopper issues that might arise, the upcoming 3.6.8rc1 is your last chance to make bugfix changes for 3.6.x. Following the successful release of 3.6.8, only security fixes will be accepted for the 3.6 branch and future 3.6.x releases will be source-only and scheduled as needed; no further binary installers will be produced for 3.6. Refer to the Dev Guide sections and release PEPs linked below for more information. https://devguide.python.org/devcycle/ https://devguide.python.org/#branchstatus https://www.python.org/dev/peps/pep-0494/ https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@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/
[python-committers] Julien Palard joins the Python Release Team as Documentation Expert
https://discuss.python.org/t/julien-palard-joins-the-python-release-team-as-documentation-expert/313 -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.1 and 3.6.7 are now available
On behalf of the Python development community and the Python 3.7 release team, we are pleased to announce the availability of Python 3.7.1. Python 3.7.1 is the first maintenance release of the newest feature release of the Python language. You can find Python 3.7.1 here: https://www.python.org/downloads/release/python-371/ See the What’s New In Python 3.7 document for more information about the many new features and optimizations included in the 3.7 series. Detailed information about the changes made in 3.7.1 can be found in its change log: https://docs.python.org/3.7/whatsnew/3.7.html https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-1-final We are also happy to announce the availability of Python 3.6.7, the next maintenance release of Python 3.6: https://www.python.org/downloads/release/python-367/ Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.1rc2 and 3.6.7rc2 now available for testing
Python 3.7.1rc2 and 3.6.7rc2 are now available. 3.7.1rc2 is a release preview of the first maintenance release of Python 3.7, the latest feature release of Python. 3.6.7rc2 is a release preview of the next maintenance release of Python 3.6, the previous feature release of Python. Assuming no further critical problems are found prior to 2018-10-20, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.1 and 3.6.7. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. You can find these releases and more information here: https://www.python.org/downloads/release/python-371rc2/ https://www.python.org/downloads/release/python-367rc2/ -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.1rc1 and 3.6.7rc1 now available for testing
Python 3.7.1rc1 and 3.6.7rc1 are now available. 3.7.1rc1 is the release preview of the first maintenance release of Python 3.7, the latest feature release of Python. 3.6.7rc1 is the release preview of the next maintenance release of Python 3.6, the previous feature release of Python. Assuming no critical problems are found prior to 2018-10-06, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.1 and 3.6.7. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. You can find these releases and more information here: https://www.python.org/downloads/release/python-371rc1/ https://www.python.org/downloads/release/python-367rc1/ -- Ned Deily n...@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/
Re: [python-committers] 3.7.1 and 3.6.7 Releases Coming Soon
On Sep 21, 2018, at 05:37, Christian Heimes wrote: > On 19/09/2018 23.12, Ned Deily wrote: >> Update: not surprisingly, there have been a number of issues that have >> popped up during and since the sprint that we would like to ensure are >> addressed in 3.7.1 and 3.6.7. In order to do so, I've been holding off on >> starting the releases. I think we are now getting close to having the >> important ones resolved so I'm going to plan on cutting off code for >> 3.7.1rc1 and 3.6.7rc1 by the end of 2018-09-20 (23:59 AoE). That's roughly >> 38 hours from now. > I'm really sorry, but would it be possible to delay the RCs until Sunday > or Monday AoE? > > Some of the XML security fixes, OpenSSL 1.1.1 fixes (TLS 1.3 > post-handshake authentication), and SSL module regression haven't landed > yet. I'm confident that I can land most to all fixes during the weekend. > > Related PRs are: > > * https://github.com/python/cpython/pull/9468 > * https://github.com/python/cpython/pull/9460 > * https://github.com/python/cpython/pull/9217 > * https://github.com/python/cpython/pull/9265 > > I'm also still collaborating with Sebastian Pipping (libexpat > maintainer) on the DoS mitigations (CVE-2013-0340). My initial patch had > some flaws. I might be able to get expat release 2.3.0 in time, too. > > https://github.com/libexpat/libexpat/pull/220 I agree that it would be good to get the security-related and OpenSSL-related fixes in sooner than later and there has been a lot going on recently. Since you have asked so nicely, I have rescheduled the cutoffs for 3.7.1rc1 and 3.6.7rc1 to be by the end of 2018-09-24 (23:59 AoE) and the final releases now on 2018-10-04. Everyone else: here are a few more days to get important things in to these releases. -- Ned Deily n...@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/
Re: [python-committers] 3.7.1 and 3.6.7 Releases Coming Soon
Update: not surprisingly, there have been a number of issues that have popped up during and since the sprint that we would like to ensure are addressed in 3.7.1 and 3.6.7. In order to do so, I've been holding off on starting the releases. I think we are now getting close to having the important ones resolved so I'm going to plan on cutting off code for 3.7.1rc1 and 3.6.7rc1 by the end of 2018-09-20 (23:59 AoE). That's roughly 38 hours from now. Thanks for all of your help in improving Python for everyone! --Ned On Sep 10, 2018, at 18:17, Ned Deily wrote: > I have now scheduled a 3.7.1 release candidate and rescheduled the 3.6.7 > release candidate for 2018-09-18, about a week from today, and 3.7.1 final > and 3.6.7 final for 2018-09-28. That allows us to take advantage of fixes > generated at the Core Developers sprint taking place this week. > > Please review any open issues you are working on or are interested in and try > to get them merged in to the 3.7 and/or 3.6 branches soon - by the beginning > of next week at the latest. As usual, if there are any issues you believe > need to be addressed prior to these releases, please ensure there are open > issues for them in the bug tracker (bugs.python.org) and that their > priorities are set accordingly (e.g. "release blocker"). -- Ned Deily n...@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/
[python-committers] 3.7.1 and 3.6.7 Releases Coming Soon
I have updated the schedules for the next maintenance releases of Python 3.7.x and 3.6.x. My original plan had been to get 3.7.1, the first 3.7 maintenance release, out by the end of July. It was solely my fault that that did not happen so I hope you'll accept my apologies; I will try to not let it happen again. I have now scheduled a 3.7.1 release candidate and rescheduled the 3.6.7 release candidate for 2018-09-18, about a week from today, and 3.7.1 final and 3.6.7 final for 2018-09-28. That allows us to take advantage of fixes generated at the Core Developers sprint taking place this week. Please review any open issues you are working on or are interested in and try to get them merged in to the 3.7 and/or 3.6 branches soon - by the beginning of next week at the latest. As usual, if there are any issues you believe need to be addressed prior to these releases, please ensure there are open issues for them in the bug tracker (bugs.python.org) and that their priorities are set accordingly (e.g. "release blocker"). Thanks for your support! --Ned -- Ned Deily n...@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/
Re: [python-committers] An alternative governance model
On Jul 17, 2018, at 22:15, Eric V. Smith wrote: > On 7/17/2018 10:02 PM, Barry Warsaw wrote: >> I’d like to propose an alternative model, and with it a succession plan, >> that IMHO hasn’t gotten enough discussion. It’s fairly radical in that it >> proposes to not actually change that much! >> TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors >> that helps the BDFL in various capacities, with additional responsibilities. >> I also have someone specific in mind for the NBDFL, but you’ll have to read >> on for the big reveal. > I've come to this same conclusion. I think Brett would be a good choice, and > I'd support him, but I think the more important part is that it be a single > person. +100. I think Python owes much of its success to both Guido's ongoing vision *and* his clear role as leader. Up to now, we have not had much experience governing by committee or council and I think it may be a mistake to try to implement that now (although we *do* have some successful experience with informal council of advisors models, for instance, in the release management area). While it wouldn't necessarily be a good choice for many (most?) open-source projects, I think the NBDFL-plus-advisors model would work well in the relatively congenial and respectful environment of the current Python committers community. That's not to say that we won't collectively decide down the road that we want to try something different but trying to keep this really important transition (i.e. from Guido) as simple as possible initially would be a really smart thing to do. > And I think the succession plan is important, too. I think Łukasz was > alluding to this earlier (or maybe I'm projecting): who's to say that the > next BDFL is legitimate? If we put together a plan, and Guido blesses it, > that makes the plan legitimate, and then the plan gets executed and makes > NBDFL legitimate. That, too. -- Ned Deily n...@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/
[python-committers] Python 3.7.0 is now available! (and so is 3.6.6)
On behalf of the Python development community and the Python 3.7 release team, we are pleased to announce the availability of Python 3.7.0. Python 3.7.0 is the newest feature release of the Python language, and it contains many new features and optimizations. You can find Python 3.7.0 here: https://www.python.org/downloads/release/python-370/ Most third-party distributors of Python should be making 3.7.0 packages available soon. See the "What’s New In Python 3.7" document (https://docs.python.org/3.7/whatsnew/3.7.html) for more information about features included in the 3.7 series. Detailed information about the changes made in 3.7.0 can be found in its change log. Maintenance releases for the 3.7 series will follow at regular intervals starting in July of 2018. We hope you enjoy Python 3.7! P.S. We are also happy to announce the availability of Python 3.6.6, the next maintenance release of Python 3.6: https://www.python.org/downloads/release/python-366/ Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ -- Ned Deily n...@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/
[python-committers] 3.7.0 / 3.6.6 Update: all systems go for final releases!
A quick update: after many months we are at the finish line. We are on track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on 2018-06-27. Since 3.7.0rc1 shipped 2 weeks ago, I am aware of only two noteworthy regressions that have been identified and now fixed. Since the issues for both have the potential to impact some (but small) subsets of 3.7.0 users and the fixes for both are straightforward and appear to be low-risk, I am planning to cherry-pick the fixes for them into 3.7.0 final without either another release candidate cycle or waiting for 3.7.1. There may be some doc fixes that get cherry-picked as well. At the moment, there are no plans for any bug cherry-picks for 3.6.6 final. As you know, a new feature release is a big deal and something for all of us to be proud of. A new feature release also has various, mostly minor, impacts to lots of different parts of our development infrastructure: to multiple branches of the cpython repo, to documentation builds, to different parts of the python.org web site, etc. You will start to see some of the changes roll out over the next 24 to 36 hours and it may take some time until everything is in place. So please be patient until the official release announcement goes out before reporting release-related issues. Also be advised that over the same period, there may be a few brief periods where commit access to various cpython branches is blocked in order to do the necessary release engineering. If you run into this, for example when trying to merge a PR, please try again in a few hours. Thanks and more later! https://bugs.python.org/issue33851 https://bugs.python.org/issue33932 -- Ned Deily n...@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/
Re: [python-committers] If I backport to 3.7, it will not go into 3.7.0, correct?
On Jun 23, 2018, at 10:31, Terry Reedy wrote: > > On 6/23/2018 8:37 AM, Eric V. Smith wrote: >> I have a few things I want to fix in 3.7.1, but don't need to be 3.7.0. I >> can backport those to the 3.7 branch now, correct? > > Correct. 'backport 3.7' == backport into 3.7.1. I have done this several > times already. > >> Reading Ned's message I wasn't exactly sure of the timing and don't want to >> screw things up. I assume he's keeping a private branch for 3.7.0. > > We no longer embargo an x.y branch during the release process, which is much > nicer. If you wanted something in 3.7.0 you would have to mark as release > blocker and be very persuasive that he should cherry-pick into the 3.7.0 > release branch. Thanks, Terry, that description is exactly right. -- Ned Deily n...@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/
[python-committers] 3.7.0rc1 and 3.6.6rc happening later today!
Short and sweet: thanks to a *lot* of work by a lot of people, we appear to be about ready to finally tag and manufacture the 3.7.0 release candidate! At the moment, we have no "release blocker" or "deferred blocker" issues open for 3.7 - a first! We also now have 21 out of 22 3.7 "production" buildbots consistently green or occasionally pink (meaning successful test retry) - also quite an accomplishment. (Only the 3.7 AIX PPC64 buildbot remains red but, since we really only support AIX on a "best effort" basis, we are not going to further delay 3.7.0 for it.) We have also had to make some tough decisions and defer some features to 3.8 and a few more complex bug resolutions to 2.7.1 or later. And releasing the "bonus beta", 3.7.0b5, resulted in some good feedback and squashing a few more issues. As you may recall, the most recently updated schedule calls for both 3.7.0rc1 and 3.6.6rc1 to be produced today, 2018-06-11, with the finals coming about two weeks later on 2018-06-27. I plan to start on 3.6.6rc1 in about 12 hours (around 22:00 UTC) with 3.7.0rc1 to follow soon thereafter. Feel free to use the remaining time to merge any last-minute documentation updates or minor bug fixes - but please do not break anything! When in doubt, ask. (I will be off-line for the next 8 hours or so.) After 3.7.0rc1 cutoff, new 3.7 merges will appear in 3.7.1, which should appear sometime next month (by the end of 2018-07). Likewise, new 3.6 merges will next appear in 3.6.7rc1, by the end of 2018-09. Please continue to exercise diligence when deciding whether a change is appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were already released and in maintenance mode. Please also pay attention to CI test failures and buildbot test failures and see if you can help resolve them. As always, if you think you may have found a critical problem at any time in either release candidate, please open (or reuse) an issue on bugs.python.org and mark it as "release blocker" priority. 3.7.0: here we come, thanks to you! --Ned -- Ned Deily n...@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/
Re: [python-committers] b.p.o. status and resolution permissions
On Jun 11, 2018, at 01:38, Tal Einat wrote: > I'm a (somewhat) new core-dev and have begun working on various issues. > > I don't have permission to change issue status and resolution on b.p.o. It > seems at this point that is holding things back and making more work for > others. I will be extra careful and only change those when I'm very sure it > is appropriate. > > Can the necessary permission bits be flipped? You should be good to go now. Welcome to the tracker! -- Ned Deily n...@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/
Re: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
On May 30, 2018, at 15:09, Donald Stufft wrote: > On May 30, 2018, at 3:03 PM, Larry Hastings 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 n...@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/
Re: [python-committers] Triage perms for Elvis
On May 29, 2018, at 17:45, R. David Murray wrote: > At Yuri's request I've given Elvis triage privileges on the tracker. > I don't anticipate any objections, given the work he's done on > What's New and other things. +1 Thanks! -- Ned Deily n...@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/
[python-committers] Python 3.7.0 updated schedule: beta 5 cutoff in 24 hours
Here's an update on the 3.7.0 endgame. As announced several days ago, we made the difficult decision to hold back on 3.7.0rc1 due primarily to some unexpected difficulties being seen downstream due to changes in how docstrings were handled in 3.7.0 (details below). After some discussions about various approaches, we agreed on a solution that should minimize downstream impact without losing all the benefits of the existing 3.7 changes. Thanks to a lot of work over the long weekend by a number of people that solution is now merged in the 3.7 branch. In parallel with that, a number of people spent a lot of time looking at CI and buildbot test failures, mostly intermittent ones. As a result, a number of actual bugs were fixed and also problems with a number of tests were fixed which should make the test suite more robust. All this is good news. Primarily because of the important user-facing changes made with the AST docstring API, I feel we need to do one more beta release before we are ready for the release candidate. About 24 hours from now, approximately 2018-05-30 18:00UTC, I plan to tag and start manufacturing 3.7.0b5. This will be a short beta cycle, aimed mainly at users of the AST API so they can recheck that their packages with 3.7.0. Assuming all goes well, we will then plan to tag 3.7.0rc1 on 2018-06-11 and 3.7.0 final on 2017-06-27. I am also rescheduling 3.6.6rc1 and 3.6.6 final to match the new 3.7.0 dates. All fixes that have been merged into the 3.7 branch as of cutoff tomorrow will be in 3.7.0b5 and fixes merged afterwards will be in 3.7.0rc1 up to its cutoff point. After 3.7.0rc1 cutoff, 3.7 merges will appear in 3.7.1. Please continue to exercise diligence when deciding whether a change is appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were already released and in maintenance mode. Please also pay attention to CI test failures and buildbot test failures and see if you can help resolve them. I want to thank everyone who has been involved so far in helping us through this endgame and who have given up their personal time to work on making Python better. I, for one, am deeply grateful. 2018-05-30 3.7.0b5 2018-06-11 3.7.0rc1 & 3.6.6rc1 2018-06-27 3.7.0final & 3.6.6final --Ned On May 25, 2018, at 01:33, Ned Deily wrote: > On May 24, 2018, at 03:23, Ned Deily wrote: >> On May 23, 2018, at 09:13, Ned Deily wrote: >>> On May 23, 2018, at 07:45, Serhiy Storchaka 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. > 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&quo
Re: [python-committers] [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch
On May 28, 2018, at 13:19, Nathaniel Smith wrote: > > Isn't that what happens if someone enables the check box at Repository > Settings -> Branches -> Branch protection rules -> [pick a branch] -> Require > branches to be up to date before merging ? Hmm, for some some reason, it appears that, at the moment, the 2.7, 3.4, and 3.5 branches have that option set, while 3.6, 3.7, and master don't. I'm not sure how we got to that state. Any other reasons to prefer on versus off? On Mon, May 28, 2018, 09:11 Brett Cannon wrote: > Ryan is right that there's no special setting in GitHub at least which would > make merging more strict for certain branches as you're describing. > > On Mon, 28 May 2018 at 07:06 Ryan Gonzalez wrote: > AFAIK there's no setting like this available, and I've done this many times > on other repos with no trouble. Maybe it could be a GitHub bug? > > On May 28, 2018 4:59:03 AM Victor Stinner wrote: > > > Hi, > > > > Since one or two weeks, I noticed that it's difficult to merge pull > > requests into the 2.7 branch. If a different commit is pushed in the > > meanwhile (if a different PR has been merged), the 2.7 branch diverges > > and the PR is immediately marked as "This branch is out-of-date with > > the base branch" and the "Squash and Merge" button is disabled (grey). > > > > For example my PR https://github.com/python/cpython/pull/7120 which > > changes Lib/test/regrtest.py cannot be merged because a commit > > touching the documentation (Doc/ directory) has been merged after I > > posted my PR and before the CI completed. > > > > I don't see the same behavior on the master branch. Is the 2.7 branch > > configured as more strict? -- Ned Deily n...@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/
[python-committers] 3.7.0rc1 Delayed [was] FINAL WEEK FOR 3.7.0 CHANGES!
On May 24, 2018, at 03:23, Ned Deily <n...@python.org> wrote: > On May 23, 2018, at 09:13, Ned Deily <n...@python.org> wrote: >> On May 23, 2018, at 07:45, Serhiy Storchaka <storch...@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. 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 tes t 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 n...@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/
Re: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
On May 24, 2018, at 13:46, Larry Hastings <la...@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 n...@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/
Re: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 24, 2018, at 12:26, Serhiy Storchaka <storch...@gmail.com> wrote: > 24.05.18 19:02, Ned Deily пише: >> On May 24, 2018, at 11:35, Serhiy Storchaka <storch...@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 n...@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/
Re: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 24, 2018, at 11:35, Serhiy Storchaka <storch...@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 n...@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/
Re: [python-committers] [Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES!
On May 24, 2018, at 07:26, Victor Stinner <vstin...@redhat.com> wrote: > 2018-05-24 9:23 GMT+02:00 Ned Deily <n...@python.org>: >> 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). > I recall that Python 3.6.0 was full of bugs, some functions like > os.waitpid() on Windows (if I recall correctly) were completely > broken. > > We can do our best to test as much as possible, hope that more and > more people use the "nightly" Python version to run their CI, but we > always miss bugs. We always get the most testers when the final x.y.0 > version is released. > > Why waiting two months to release bugfixes? We're not planning on waiting two months. First, 3.7.0 final is not planned to release until 2018-06-15; if necessary, there could be one or more emergency bug fixes in it. Second, "before the end of July (< 2018-07-31)" does not mean we have to wait until the end of July. If necessary, it could be near the beginning of the month, so closer to two weeks after the release. Right now, our focus should be on getting high-quality 3.7.0rc1 and 3.7.0 final releases out there to our users and then we can focus on what comes next. Getting close! -- Ned Deily n...@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/
Re: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 23, 2018, at 09:13, Ned Deily <n...@python.org> wrote: > On May 23, 2018, at 07:45, Serhiy Storchaka <storch...@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 n...@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/
Re: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
On May 23, 2018, at 07:45, Serhiy Storchaka <storch...@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 n...@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/
Re: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
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 n...@python.org -- [] > On May 17, 2018, at 14:31, Serhiy Storchaka <storch...@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. > ___ 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/
[python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
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 n...@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/
[python-committers] [RELEASE] Python 3.7.0b4, final 3.7 beta, now available for testing
Python 3.7.0b4 is the final beta preview of Python 3.7, the next feature release of Python. Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare your projects to support the new feature release. We strongly encourage you to test your projects with 3.7 during the beta phase and report issues found to bugs.python.org as soon as possible. While the release is feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. Attention macOS users: there is now a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! The next preview release will be the release candidate and is planned for 2018-05-21 followed by the official release of 3.7.0, planned for 2018-06-15. You can find Python 3.7.0b4 and more information here: https://www.python.org/downloads/release/python-370b4/ -- Ned Deily n...@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/
[python-committers] IMPORTANT - final 3.7.0 beta cutoff!
Just a reminder that 3.7.0b4 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-04-30 ~23:59 Anywhere on Earth (UTC-12:00). That's about 16 hours from now. IMPORTANT: We are now in the final phase of 3.7.0. Tomorrow's 3.7.0b4 is the final beta planned for 3.7.0. After tomorrow, the next planned release is the 3.7.0 release candidate, on 2018-05-21, for final testing. Our goal is to have no changes between the release candidate and final; after rc1, changes applied to the 3.7 branch will be released in 3.7.1. Between now and the rc1 cutoff, 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. Also, during the time leading up to the release candidate, we will be completing the What's New in 3.7 document. 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! --Ned -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.0b3 is now available for testing
On behalf of the Python development community and the Python 3.7 release team, I'm happy to announce the availability of Python 3.7.0b3. b3 is the third of four planned beta releases of Python 3.7, the next major release of Python, and marks the end of the feature development phase for 3.7. You can find Python 3.7.0b3 here: https://www.python.org/downloads/release/python-370b3/ Among the new major new features in Python 3.7 are: * PEP 538, Coercing the legacy C locale to a UTF-8 based locale * PEP 539, A New C-API for Thread-Local Storage in CPython * PEP 540, UTF-8 mode * PEP 552, Deterministic pyc * PEP 553, Built-in breakpoint() * PEP 557, Data Classes * PEP 560, Core support for typing module and generic types * PEP 562, Module __getattr__ and __dir__ * PEP 563, Postponed Evaluation of Annotations * PEP 564, Time functions with nanosecond resolution * PEP 565, Show DeprecationWarning in __main__ * PEP 567, Context Variables Please see "What’s New In Python 3.7" for more information. Additional documentation for these features and for other changes will be provided during the beta phase. https://docs.python.org/3.7/whatsnew/3.7.html Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage you to test your projects with 3.7 during the beta phase and report issues found to https://bugs.python.org as soon as possible. While the release is feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2018-05-21). Our goal is have no ABI changes after beta 3 and no code changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Attention macOS users: there is a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! We welcome your feedback. As of 3.7.0b3, the legacy 10.6+ installer also includes a built-in Tcl/Tk 8.6. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next planned release of Python 3.7 will be 3.7.0b4, currently scheduled for 2018-04-30. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.6.5 is now available
Python 3.6.5 is now available. 3.6.5 is the fifth maintenance release of Python 3.6, which was initially released in 2016-12 to great interest. Detailed information about the changes made in 3.6.5 can be found in its change log. You can find Python 3.6.5 and more information here: https://www.python.org/downloads/release/python-365/ See the "What’s New In Python 3.6" document for more information about features included in the 3.6 series. Detailed information about the changes made in 3.6.5 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-5-final Attention macOS users: as of 3.6.5, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default variant in future releases. Check it out! The next maintenance release is expected to follow in about 3 months, around the end of 2018-06. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation: https://www.python.org/psf/ -- Ned Deily n...@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/
[python-committers] IMPORTANT - 3.7.0b3 cutoff / 3.7.0 ABI freeze
Just a reminder that 3.7.0b3 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-03-26 ~23:59 Anywhere on Earth (UTC-12:00). That's a little over 3.5 days from now. IMPORTANT: We are now entering the final phases of 3.7.0. After the tagging for 3.7.0b3, the intention is that the ABI for 3.7.0 is frozen. After next week's 3.7.0b3, there will only be two more opportunities planned for changes prior to 3.7.0 final: - 2018-04-30 3.7.0 beta 4 - 2018-05-31 3.7.0 release candidate As I've noted in previous communications, we need to start locking down 3.7.0 so that our downstream users, that is, third-party package developers, Python distributors, and end users, can test their code with confidence that the actual release of 3.7.0 will hold no unpleasant surprises. So after 3.7.0b3, you should treat the 3.7 branch as if it is 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! --Ned -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.6.5rc1 is now available for testing
Announcing the immediate availability of Python 3.6.5 release candidate 1! Python 3.6.5rc1 is the first release candidate for Python 3.6.5, the next maintenance release of Python 3.6. While 3.6.5rc1 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). 3.6.5 is planned for final release on 2018-03-26 with the next maintenance release expected to follow in about 3 months. You can find Python 3.6.5rc1 and more information here: https://www.python.org/downloads/release/python-365rc1/ Attention macOS users: as of 3.6.5rc1, there is a new additional installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default variant in future releases. Check it out! -- Ned Deily n...@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/
[python-committers] Reminder: 3.6.5rc1 cutoff coming up
A quick reminder that it's time for our next quarterly maintenance release of Python 3.6. The cutoff for 3.6.5rc1 is planned for 2018-03-12 end-of-the-day AOE. Please get any bug fixes and doc changes in before then. Expect that any changes merged after the 3.6.5rc1 cutoff will be released in 3.6.6 which is currently scheduled for 2018-06 (along with 3.7.0). Also, a reminder that 3.6.x has been out in the field for nearly 15 months now and thanks to all of your hard work in previous feature releases and during the 3.6 development phase, the 3.6 release series has seen remarkably quick adoption to overall great acclaim. Now that 3.6 has reached a certain level of maturity, it is important for all of us to continue to focus on stability for all of its downstream users. A key assumption of our maintenance strategy for years has been that we as a project will only maintain the most recent bugfix (or security) release. In other words, when we release x.y.z, we immediately drop support for x.y.z-1. To do that, we implicitly promise to users that they can "painlessly" upgrade from any x.y.n to x.y.z where n < z. To try to keep that promise, we strive to make no incompatible changes in x.y.z without *really* good reasons. I think it is important as 3.6 moves along in its lifecycle to put ourselves in the shoes of our users and ask ourselve s if a change is really appropriate at this stage. There's no hard and fast rule here, just continue to use your best judgement. When in doubt, ask! FYI, I've adjusted the 3.6.x release schedule to allow for 2 additional quarterly maintenance releases after 3.7.0 releases instead of just one. That means the final bugfix release for the 3.6 series is planned to be 3.6.8 in 2018-12, 6 months after 3.7.0 releases and 2 years after 3.6.0 first released. Thereafter, only security issues will be accepted and addressed for the remaining life of 3.6. Thanks again! --Ned https://www.python.org/dev/peps/pep-0494/ -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.0b2 is now available for testing
On behalf of the Python development community and the Python 3.7 release team, I'm happy to announce the availability of Python 3.7.0b2. b2 is the second of four planned beta releases of Python 3.7, the next major release of Python, and marks the end of the feature development phase for 3.7. You can find Python 3.7.0b2 here: https://www.python.org/downloads/release/python-370b2/ Among the new major new features in Python 3.7 are: * PEP 538, Coercing the legacy C locale to a UTF-8 based locale * PEP 539, A New C-API for Thread-Local Storage in CPython * PEP 540, UTF-8 mode * PEP 552, Deterministic pyc * PEP 553, Built-in breakpoint() * PEP 557, Data Classes * PEP 560, Core support for typing module and generic types * PEP 562, Module __getattr__ and __dir__ * PEP 563, Postponed Evaluation of Annotations * PEP 564, Time functions with nanosecond resolution * PEP 565, Show DeprecationWarning in __main__ * PEP 567, Context Variables Please see "What’s New In Python 3.7" for more information. Additional documentation for these features and for other changes will be provided during the beta phase. https://docs.python.org/3.7/whatsnew/3.7.html Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage you to test your projects with 3.7 during the beta phase and report issues found to https://bugs.python.org as soon as possible. While the release is feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2018-05-21). Our goal is have no ABI changes after beta 3 and no code changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Attention macOS users: as of b1, there is a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! We welcome your feedback. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next planned release of Python 3.7 will be 3.7.0b3, currently scheduled for 2018-03-26. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@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/
[python-committers] 3.7.0b2 code cutoff soon!
Just a reminder that 3.7.0b2 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-02-26 ~23:59 Anywhere on Earth (UTC-12:00). That's a little over 1.5 days from now. Also, as previously noted, for those of you who asked for and received extensions for a few remaining 3.7.0 features, those extensions expire as of the b2 cutoff so please plan accordingly. Looking ahead, we need to start locking down 3.7.0 so that our downstream users, that is, third-party package developers, Python distributors, and end users, can test their code with confidence that the actual release of 3.7.0 will hold no unpleasant surprises. So please assume that the 3.7.0 ABI will be frozen as of beta 3, in 4 weeks on 2018-03-26, and that only doc updates and the kinds of bug fixes appropriate for a maintenance release should be going into the 3.7 branch after 3.7.0b3 without further discussion. Thanks again for all of your hard work towards making 3.7.0 yet another great release! --Ned -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.0b1 is now available for testing
On behalf of the Python development community and the Python 3.7 release team, I'm happy to announce the availability of Python 3.7.0b1. b1 is the first of four planned beta releases of Python 3.7, the next major release of Python, and marks the end of the feature development phase for 3.7. You can find Python 3.7.0b1 here: https://www.python.org/downloads/release/python-370b1/ Among the new major new features in Python 3.7 are: * PEP 538, Coercing the legacy C locale to a UTF-8 based locale * PEP 539, A New C-API for Thread-Local Storage in CPython * PEP 540, UTF-8 mode * PEP 552, Deterministic pyc * PEP 553, Built-in breakpoint() * PEP 557, Data Classes * PEP 560, Core support for typing module and generic types * PEP 562, Module __getattr__ and __dir__ * PEP 563, Postponed Evaluation of Annotations * PEP 564, Time functions with nanosecond resolution * PEP 565, Show DeprecationWarning in __main__ * PEP 567, Context Variables Please see "What’s New In Python 3.7" for more information. Additional documentation for these features and for other changes will be provided during the beta phase. https://docs.python.org/3.7/whatsnew/3.7.html Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage you to test your projects with 3.7 during the beta phase and report issues found to https://bugs.python.org as soon as possible. While the release is feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2018-05-21). Our goal is have no ABI changes after beta 3 and no code changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Attention macOS users: with 3.7.0b1, we are providing a choice of two binary installers. The new variant provides a 64-bit-only version for macOS 10.9 and later systems; this variant also now includes its own built-in version of Tcl/Tk 8.6. We welcome your feedback. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next planned release of Python 3.7 will be 3.7.0b2, currently scheduled for 2018-02-26. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@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/
[python-committers] [IMPORTANT] post 3.7.0b1 development now open
Here we are: 3.7.0b1 and feature code freeze! Congratulations and thanks to all of you who've contributed to the huge number of PEPs, features, bug fixes, and doc changes that have gone into 3.7 since feature development began back in September 2016, after 3.6.0b1, 3.6's feature freeze. Now that feature development for 3.7 is over, the challenge is to put the finishing touches on the features and documentation, squash bugs, and test test test. In the cpython repo, there is now a 3.7 branch. Starting now, all PRs destined for 3.7.0 should get cherry-picked from master to the 3.7 branch or just pushed to 3.7 if only applicable there. New features should continue to be pushed to the master branch for release in 3.8; no new features are now permitted in 3.7 unless you have contacted me and we have agreed on an extension (and all granted extensions will expire as of 3.7.0b2). As before, bug fixes appropriate for 3.6.x should continue to be cherry-picked to the 3.6 branch. I've updated the Developer's Guide to reflect the now current workflow. Let me know if you find any bugs in it. Likewise, please contact me if you have any questions about the workflow or about whether a change is appropriate for 3.7 beta. The cpython repo on Github has been updated. You should now find that builds on the master branch produce a Python 3.8, rather than 3.7; you may want to clean your build directory. And there is now a 3.7 branch that you will need to use for 3.7 builds and pushs. There were several PRs that were merged to master over the last couple of days since we started 3.7.0b1 release engineering. All but one of those have been cherry-picked into the new 3.7 branch and you should have seen messages for them. One was for a 3.8 feature and so was not backported. At the moment, the new 3.7 buildbots may not be fully operational but they should be soon. Likewise, the docs.python.org may take up to 24 hours to reflect all the changes. Note that is the first time we've done a feature freeze using our new git-based workflow, so there's likely that there might be a glitch or something overlooked. Please let us know if you suspect something or have a question. I'll be around here and or #python-dev. Also, don't forget to direct 3.8-related questions to Łukasz. Welcome on-board! To recap: 2018-01-31: 3.7 branch open for 3.7.0; 3.8.0 feature development begins 2018-01-31 to 2018-05-21: 3.7.0 beta phase (no new 3.7 features) - push PRs for new features, bugs, regressions, doc fixes to the master branch for release in 3.8 - cherry-pick or push PRs for 3.7.0 (bug/regression/doc fixes) to the new 3.7 branch - cherry-pick or push select PRs for important bug/regression/doc fixes to 3.6 and 2.7 branches as appropriate - propose PRs to 3.5 and 3.4 branches for any identified security issues 2018-02-26: 3.7.0 beta 2 (next beta preview) 2018-03-26: 3.7.0 beta 3 (3.7.0 ABI freeze) 2018-04-30: 3.7.0 beta 4 (only critical and urgent fixes after this point) 2018-05-21: 3.7.0 release candidate 1 (3.7.0 code freeze, only any emergency fixes afer this point) 2018-06-15: 3.7.0 release 2019-10-20: 3.8.0 release (next planned feature release, see PEP 569) Thank you all again for your great efforts so far on 3.7! --Ned ___ 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/
Re: [python-committers] 3.7.0b1 status
On Jan 31, 2018, at 16:14, Ned Deily <n...@python.org> wrote: > Hang tight, I'm working on that right at this moment :) Almost ready! FYI, I'm going to lock the master branch for a brief period starting right now to do the cutover to 3.8. I'll let you know when it's unlocked. -- Ned Deily n...@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/
Re: [python-committers] 3.7.0b1 status
On Jan 31, 2018, at 16:03, R. David Murray <rdmur...@bitdance.com> wrote: > > Hmm. I merge something and put on the backport 3.6 label and just > merged that...and I have no idea if the 3.7 merge was before or > after the b1 cutoff. Is there some way to get git to tell us which > commits are possible candidates for cherry picking after the branch > is created so that we don't miss any? Otherwise I fear we may > end up with some bug fixes that get in to 3.8 and 3.6 but not 3.7. Hang tight, I'm working on that right at this moment :) Almost ready! -- Ned Deily n...@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/
[python-committers] 3.7.0b1 status
Just a quick update: thanks to all of you who worked long hours to get features completed and merged in for the 3.7 feature code cutoff yesterday. We release elves have been busy behind the scenes baking goodies. So far everything looks OK. But we're taking a little longer than usual: this is, in many ways, the most complicated milestone of the release cycle, since it involves creating a new release branch and other munging, and this is the first time we are doing this since we moved to our new git-based workflow last year and we want to get it right. We will have everything done and announced in not more than 24 hours from now. If you wish, feel free to merge new commits into the master branch for release in 3.8, with the understanding that any also destined for 3.7.0 will need to be cherrypicked after the 3.7 branch is available. Other branches (3.6, 2.7) are unaffected. Thanks for your patience! -- Ned Deily n...@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/
[python-committers] IMPORTANT: 3.7.0b1 and feature code cutoff 2018-01-29
Happy mid-winter (northern hemisphere) or -summer (southern)! The time has come to finish feature development for Python 3.7. As previously announced, this coming Monday marks the end of the alpha phase of the release cycle and the beginning of the beta phase. Up through the alpha phase, there has been unrestricted feature development phase; that ends as of beta 1. All feature code for 3.7.0 must be checked in by the b1 cutoff on end-of-day Monday (unless you have contacted me and we have agreed on an extension). As was done during the 3.6 release cycle, we will create the 3.7 branch at b1 time. During the beta phase, the emphasis is on fixes for new features, fixes for all categories of bugs and regressions, and documentation fixes/updates. I will send out specific information for core committers next week after the creation of the b1 tag and the 3.7 branch. Beta releases are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.7 during the beta phase and report issues found to bugs.python.org as soon as possible. While the release will be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase. Our goal is have no changes after rc1. To achieve that, it will be extremely important to get as much exposure for 3.7 as possible during the beta phase. Also, during the 3.6.0 release cycle, the question of ABI stability during the final (e.g. beta and release candidate) phases of the release came up. Last-minute changes put a burden on our and our downstream users testing efforts and adds risk to the release. Therefore, as was proposed then, we will strive to have no ABI changes after beta 3. More details forthcoming. To recap: 2018-01-29 ~23:59 Anywhere on Earth (UTC-12:00): code snapshot for 3.7.0 beta 1 (feature code freeze, no new features) 2019-01-30: 3.7 branch opens for 3.7.0 feature development continues on master branch, now for 3.8.0 2018-01-30 to 2018-05-21: 3.7.0 beta phase (bug, regression, and doc fixes, no new features) 2018-03-26: 3.7.0 beta 3 (3.7.0 ABI freeze) 2018-05-21: 3.7.0 release candidate 1 (3.7.0 code freeze) 2018-06-15: 3.7.0 release (3.7.0rc1 plus, if necessary, any dire emergency fixes) ~2019-12 tentative (3.7.0 release + 18 months): 3.8.0 release (details TBD) Thank you all for your great efforts so far on 3.7; it should be another great release! --Ned https://www.python.org/dev/peps/pep-0537/ -- Ned Deily n...@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/
Re: [python-committers] trivial tag on GitHub?
On Jan 26, 2018, at 16:05, Ethan Furman <et...@stoneleaf.us> wrote: > On 01/26/2018 09:28 AM, Mariatta Wijaya wrote: > >>So when the original PR didn't have a news entry, what should I have seen >> to alert me to that? >> >> If a news entry is missing from the PR, the CI check at the bottom of the PR >> will fail. >> You should see the following: >> >> bedevere/news -- No news entry in Misc/NEWS.d/next/ or "skip news" label >> found >> >> An example can be seen here (at least at the time I write this email) >> https://github.com/python/cpython/pull/5347 > > Okay, I see it in your example. Here's the PR I'm talking about: > > https://github.com/python/cpython/pull/5103 > > I see no NEWS commit, and no "missing news" alert. Did I misstep somewhere? It's all the way at the bottom, generated by blurb: Misc/NEWS.d/next/Library/2018-01-04-14-45-33.bpo-29237.zenYA6.rst https://github.com/python/cpython/pull/5103/files -- Ned Deily n...@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/
[python-committers] [RELEASE] Python 3.7.0a4 is now available for testing
Python 3.7.0a4 is the last of four planned alpha releases of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.7.0b1, is planned for 2018-01-29. You can find Python 3.7.0a4 and more information here: https://www.python.org/downloads/release/python-370a4/ -- Ned Deily n...@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/
Re: [python-committers] Promote Julien Palard as core developer
On Dec 6, 2017, at 19:48, Victor Stinner <victor.stin...@gmail.com> wrote: > I propose to promote Julien Palard as a core developer. A big +2 from me. Julien has been extremely helpful over the past half year or so with multiple behind-the-scenes documentation build issues. As Victor notes, he is familiar with the doc infrastructure, processes, and the people who work on them. I've found him to be easy to work with and to display good judgement. I would be very happy to see Julien take on a more formal role with our documentation process and any other area that he would like to get involved with. -- Ned Deily n...@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/
Re: [python-committers] Adding Ivan Levkivskyi as a core committer
On Dec 6, 2017, at 11:57, Mariatta Wijaya <mariatta.wij...@gmail.com> wrote: > On Dec 6, 2017 8:44 AM, "Guido van Rossum" <gu...@python.org> wrote: >> I think I figured it out -- I invited him to the python org on GitHub. >> Anything else? > Please add Ivan to the Developer Log in Dev Guide, and he should subscribe to > python-committers mailing list :) It should all be here in the Devguide: https://devguide.python.org/coredev/#gaining-commit-privileges -- Ned Deily n...@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/
