On Thu., 20 Dec. 2018, 3:46 am Brett Cannon <br...@python.org wrote: > > On Wed, 19 Dec 2018 at 06:01, Victor Stinner <vstin...@redhat.com> wrote: > >> >> > >> 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: >> >> https://github.com/elpython/elpython-meta > > > Was that when >
If the unfinished question there is "... when Nick was still working for Red Hat?", then yeah, it was. I knew RHEL 8 was coming with Py3.6 as the system Python, and wanted a way to avoid the anchoring effects that Alex Gaynor and I talked about a few years back in https://alexgaynor.net/2015/mar/30/red-hat-open-source-community/ and https://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html I still think ELPython is a good idea, as it should solve a bunch of the problems that Alex raised on the community side, while also helping commercial distributors (including Red Hat) provide the explicitly in demand commercial service of compatible *feature* backports to LTS releases (go look at the system Python 2.6 install in RHEL 6, for example - it includes a number of 2.7 features, such as collections.OrderedDict). Red Hat's provided that service for years for their Linux kernels, and it's one of the capabilities that their customers most value. The community benefit of allowing such backports to take place in a cross-vendor collaborative project is that it would allow popular backwards compatible features to be adopted by library authors more quickly, as they'd have the option of switching to relying on the EL variant of a release for a feature they wanted, rather than having to drop that release stream entirely. However, I also deliberately designed the proposal to make it clear it was only going to happen as a *paid* activity, with a bright line for contributions where the only reason for a volunteer to take their change across that line would be because they wanted the new behaviour in the EL version themselves. Thus the notion of a separate GitHub org, source-only releases, different runtime identification metadata, etc. Actually pursuing that project would still need a PEP to spell out the relationship between CPython and the ELPython derivative, though. Pursuing the project would also need credible commitments from redistributors to actually adopt the variant - the technical design in the README is explicitly constructed so it would work as a drop-in replacement for the RHEL 8 system Python, but at the time I left RH, Petr Viktorin and I didn't have agreement from management yet that that was a path the company wanted to go down (and it was only recently, when the RHEL 8 public beta dropped, that we gained the ability to discuss the commercial motivation for the idea with the upstream community). Cheers, Nick. > >> >>
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
