On 29 August 2016 at 19:14, Chris Angelico <ros...@gmail.com> wrote: > On Mon, Aug 29, 2016 at 6:24 PM, Christian Heimes <christ...@python.org> > wrote: >> No, LTS support should not be our concern. If you need a brand new >> version of Python on an old LTS or Enterprise version of your OS, please >> contact your vendor and buy support. You don't get to run old metal and >> play with shiny new toys at the same time for free. > > I think I agree with you, but I'm not fully convinced. The current > stable Debian (Jessie) also ships OpenSSL 1.0.1, although 1.0.2 is > available in backports. The next stable release (Stretch) is expected > some time 2017.
I agree keeping build compatibility with the latest Debian stable release is a sensible baseline, but 3.7 won't land until some time in 2018, so Christian's proposed timeline still works on that front (but jumping straight to requiring 1.0.2 in 3.6 wouldn't, suggesting that supporting the latest Debian stable release will be a genuinely useful guideline in helping to make decisions about minimum supported OpenSSL versions for new CPython releases). Assuming the checks for required OpenSSL features are able to be implemented as feature guards rather than as a plain version check (e.g. by issuing a warning if the detected SSL version is too low, but otherwise letting the build continue), other distros will also be able to keep new CPython versions building just by backporting the required OpenSSL features. More generally, it's important for folks to keep in mind that where most commercial Linux redistributors invest directly in upstream maintenance by assigning people to work on the kernel and other low level infrastructure pieces full time (including the community distros where those components are most actively developed), Python's commercial redistributors aren't as well behaved, so we currently have just the one full time developer working on PyPI and related PyPA tooling, and a few folks that have successfully negotiated part-time upstream CPython involvement as a condition of their employment. That disparity means we have to start getting much better at offloading security-sensitive work from CPython's volunteers to paid Linux developers in cases where it's feasible for us to do so, even if that in turn means requiring that Linux distros (both community and commercial) pay much closer attention to keeping their network security libraries up to date if they want their users to be readily able to build and run the latest Python feature releases. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
