[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

[Nick Coghlan]

On 24 March 2014 23:49, Skip Montanaro <skip at pobox.com> wrote:
> So what's the big deal? Why can't we be pragmatic and call this thing
> (whatever it turns out to be) 2.8? Is this pledge and its rationale
> written down in a PEP somewhere, so I can study the reasons behind
> what appears at this point to be blind adherence?

There's a ton of work involved in creating a new feature release, and
there's no way we're going to go through that much drudgery for the
legacy Python 2 series without someone paying for it. Even the more
limited network security infrastructure update proposal in this PEP is
conditional on corporate contributors agreeing to do the heavy
lifting.

> Did someone
> administer a blood oath at a recent PyCon?

As discussed in the PEP, a Python 2.8 release wouldn't actually solve
this problem, so there's no reason for commercial redistributors to
contribute to making it happen.

For example, RHEL7 and derivatives are already locked in to 2.7 until
2024, RHEL6 and derivatives are locked in to 2.6 until 2020. The only
way to keep those combination of RHEL and the Python 2 standard
library from holding back the evolution of internet security standards
is to find a way solve the problem *within* the 2.7 line in such a way
that I can then make the case for also backporting it to 2.6 in a
RHEL6 point release.

I think the proposal currently in round 3 of the PEP is something I
can sell to the Platform Engineering team as a necessary update to
make in a relatively timely fashion (I don't think the situation is
critical yet, but give it another year or two and I'll be a lot more
concerned). By contrast, trying to handle this via a Python 2.8
release would mean I would still have to advocate for us to adopt the
policy in the PEP independently of upstream, and that's not a good
outcome for anyone.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia