Hi,
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. 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.
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:
https://github.com/elpython/elpython-meta
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:
https://www.kernel.org/category/releases.html
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.