[python-committers] Extending 3.6 [was: 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!]

[Ned Deily]

On Dec 19, 2018, at 04:14, Serhiy Storchaka <storchaka at 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 at 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 at python.org -- []