Another essential bit of tooling for the migration:
* Before filing a bug report or feature request, we ask people to search to see if there is already an issue in progress or a resolved issue on the topic. We need to make sure that on GitHub issues, people can still search our voluminous history of already evaluated and decided feature requests.
Raymond
On behalf of the Python development community, I'm chuffed to announce
the availability of Python 3.5.8rc1.
Python 3.5 is in "security fixes only" mode. This new version only
contains security fixes, not conventional bug fixes, and it is a
source-only release.
You can find Python 3.5.8rc1 here:
https://www.python.org/downloads/release/python-358rc1/
I think Python 3.5 may just barely outlive 2.7,
//arry/
Team,
amazing job on getting us back on track over the weekend.
Thank you
All release blockers and deferred release blockers solved. And there was relatively little additional activity on the branch -- as expected at this point! Thank you for this, it will help get the release candidate out on time.
I'm working on cutting RC1 today
Hopefully all sanity checks, as well as building the source tarball and the binary installers for macOS and Windows will all work out fine and we'll be seeing RC1 out tonight.
RC2 and the date of 3.8.0 gold
If we manage to avoid the need for RC2, we will be able to release 3.8.0 on October 14th. If we need an RC2, that will slip by a week. I hope we won't. Ideally RC1 should be identical codewise to 3.8.0.
To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.)
Note I didn't say I forbid any activity. I have no power over you, actually. More importantly though, I trust your judgement if you assess some bug is bad enough the fix absolutely has to get into 3.8.0. Moreover, I specifically said source-related activity because...
3.8.0 is important. To some users it will be the first and the last release in the 3.8 series they will see.
We need you to focus on the docs now
Are all your changes properly documented?
Did you notice other changes you know of to have insufficient documentation?
Can you help with the "What's New" document?
anxiously configure-&&-makingly y'rs
- Ł
Hi folks -
Per PEP 13, a new Steering Council will be voted in after each feature
release. As Victor has pointed out, 3.8 is scheduled for 2019-10-21 so we
should start talking about the election.
The Steering Council discussed this and the timeline proposed for the vote
is as follows:
* The nomination period will begin Nov 1, 2019 (do not post nominations
until then)
* Nomination period will end Nov 15, 2019
* Voting will begin Dec 1, 2019
* Voting will end Dec 15
Nominations will be collected via https://discuss.python.org/ (more details
to follow). I will be handling all the email notifications related to the
election and Ernest will continue to run the elections. I will send more
information out in a couple of weeks.
In the meantime, don't hesitate to reach out if you have any questions or
concerns.
Thank you,
Ewa
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
nad(a)python.org -- []
While we wait for the last step of the infrastructure team to add Joannah
to the Python Core team on GitHub, I wanted to welcome to the development
team!
Hi,
The PEP 13 says "A new council is elected after each feature release."
Does it mean that we need elect a new Steering Council before/after
Python 3.8.0 final release which is scheduled at 2019-10-21 (in more
or less one month)?
If a vote is organized, when should "Candidates advertise their
interest in serving"? What will be the duration of the election phases
and who will manage the vote?
https://www.python.org/dev/peps/pep-0013/#electing-the-council
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
Howdy howdy. Here's what I'm thinking for the next release of 3.5.
This week I'm going to merge / reject all the outstanding PRs for 3.5,
then cut rc1 at the Python Core Dev sprints next week, either Monday
(2019/9/9) or Tuesday (2019/9/10). This isn't a lot of notice, but
things have slowed down a lot for 3.5, so I suspect nobody's going to be
inconvenienced or bothered by the short notice.
However! If you /would/ be inconvenienced or bothered by the short
notice--if you need more time to get a patch in for 3.5--just let me
know and I can delay rc1.
Assuming no problems crop up in rc1, 3.5.8 final will be released two
weeks after 3.5.8 rc1.
Cheers,
//arry/
PEP 1 currently says that if a PEP is authored by a non-core developer, the author must find a core developer to sponsor their PEP. At today’s Steering Council meeting, we proposed to relax this requirement to allow non-core developers to sponsor a PEP with the approval of the Council. There is no change if the PEP author is a core developer; in that case the PEP still does not require a sponsor.
Here is the PR with the proposed language change:
https://github.com/python/peps/pull/1170
Feel free to weigh in on the PR.
Cheers,
-Barry
