On 12/23/18 2:08 AM, Nick Coghlan wrote:
On Thu., 20 Dec. 2018, 3:46 am Brett Cannon <br...@python.org
<mailto:br...@python.org> wrote:
On Wed, 19 Dec 2018 at 06:01, Victor Stinner <vstin...@redhat.com
<mailto: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).
(with my RH hat on; despite my personal address:)
If anyone wants to collaborate, I'd be happy go push the EL Python idea
further. But, so far, we haven't found other organizations that would
want to join the effort. (BTW, I think Victor asking CPython devs
themselves was a very long shot, but at least it confirmed that the
answer is "no".)
So it looks like we'll keep the status quo – Red Hat's patches to 3.6
will be available in Red Hat & CentOS repos.
_______________________________________________
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/
