On Dec 19, 2018, at 04:14, Serhiy Storchaka <storchaka@gmail.com> 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 <greg@krypto.org> 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, Serihy, and thanks for everyone's thoughtful responses.
-- Ned Deily nad@python.org -- []