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.
On Wed, Dec 19, 2018 at 9:46 AM Brett Cannon email@example.com wrote:
[Dropping python-dev so we don't end up swamping the python-committers admins -- i.e. me :) -- with posts held for moderation]
On Wed, 19 Dec 2018 at 06:01, Victor Stinner firstname.lastname@example.org wrote:
I am working in the Red Hat "Python-maint" team which is maintaining Python 3.6 as the main Python interpreter in RHEL 8, which will likely be supported for at least 10 years. And we have been supporting Python 2.7 in RHEL 7. So obviously, being able to benefit of the upstream effort and infra to have a Python 3.6 Long Time Support (LTS) would help us :-)
The question is more who else would benefit from that and is it worth it? I don't want Python upstream to pay the price of the maintenance burden of RHEL 8 lifecycle.
And for me that extends to Ubuntu LTS releases as well.
For example, supporting a version means to have a working CI (Travis CI, AppVeyor, VSTS, buildbots). I would suggest to only support a very few platforms for the LTS. I propose to restrict to Linux. It doesn't mean to break other platforms on purpose, just to restrict CI to the bare minimum. If Microsoft is interested, we can also support Windows as well.
But that doesn't help someone like me who isn't working on Linux, so it's still work to support just Linux compared to Windows or macOS. Plus supporting just Linux in CI and such is still not free either.
RHEL 7 is based on Python 2.7.5 which has been released in 2013 (5 years ago) and there are 150 patches on top of it: it means that around 30 patches are added per year. I would suggest to have a very strict policy on which changes are backported into 3.6: only the most critical bugfixes, but all security fixes obviously.
If we extend Python 3.6 lifetime, do we need a new release manager when the initial lifetime (usually 5 years) ends? Benjamin Peterson accepted to be the Python 2.7 release manager for 10 years (instead of 5 years initially). We could ask Ned Deily about Python 3.6 LTS :-) We would need a group of people reviewing individual 3.6 pull requests to decide to pick them or not. I would volunteer to review these PRs and merge them.
The idea isn't new, Nick Coghlan proposed a "ELPython" last year:
Was that when
The Linux kernel also have multiple LTS kernel which are supported longer than usual releases: they are now supported for 6 years. See "Longterm" at:
The LKM has plenty of paid, full-time employees to keep those LTS kernels running upstream while we have nothing close to that. Even if we said "no one is expected to manage 3.6 changes" to let paid core devs keep 3.6 going, that still adds overhead to other core devs who have no interest in keeping 3.6 alive for Canonical or RH's benefit (yes, the community gets benefits as well, but I would argue the pay-off isn't high enough for volunteers to be involved). Now if downstream vendors wanted to get together to pool their resources to make 3.6 a LTS-like release in a separate repo then I would be fine with that.
I also think this puts Ned in a tough position to say "no" to the request if people start saying "I would love more free support!" ;) . _______________________________________________ python-committers mailing list email@example.com https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/