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

[Nick Coghlan]

On 23 March 2014 08:40, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Am 22.03.14 23:33, schrieb Nick Coghlan:
>> Hard to maintain legacy software is a fact of life, and way too much
>> of it is exposed to the public internet. This PEP is about doing what
>> we can to mitigate the damage caused both by other people's mistakes,
>> and also the inherent challenges of migrating from the error prone
>> POSIX text model to something more reasonable.
>>
>> I *don't* think its reasonable to expect us to do this without support
>> from the corporate users that caused the problem in the first place
>> (by continuing to deploy older versions of Python without investing
>> adequately in their upkeep), so I'd encourage everyone employed by a
>> commercial user of Python to remind their management chains of the
>> risks of failing to invest development time in any upstream
>> dependencies that they expect to keep pace with the dynamic nature of
>> the internet.
>
> I hope indeed you are successful in activating resources. However,
> putting them on this backporting project seems like a waste. They
> should rather go into porting stuff to 3.x where people need it.

Red Hat will be supporting Python 2.6 until 2020'ish, Python 2.7 until
at least 2024 (since RHEL7 isn't actually out yet). Python 2 is part
of one of our core products (RHEL), and a dependency of another one
(OpenStack).

While the wheels are in motion upstream to migrate both to Python 3,
that's a long term project in both cases, and really hard to make a
business case for. While we do believe the open source way delivers
better software in the long run, we still have to make our case when
we want the company to spend time and resources on something.

> As responsible maintainers, we should just advise our users that
> Python 2.7 is a dead horse, and that they should stop riding it.
> More professionally, we should set an official end-of-life date
> for 2.7 (alas, we should have done that two years ago).

This completely ignores the practical realities of commercial software
development, and the commitments that vendors have made to their
customers.

I agree it would be completely unreasonable to ask volunteers to
contribute their own time to making this proposal work. However, it's
likely to be much easier for those of us with influence in the
commercial world to shake some resources loose if we have a
pre-arranged agreement on the specific help we need to better support
their interests.

> I hope that the language summit can agree to stopping bug fix
> releases for 2.7 in 2014.

I'd rather come up with a plan to seek dedicated resources from key
corporate users to help with the boring parts of long term maintenance
that are really hard to get volunteers excited about, but make a great
avenue for corporate sponsored contributions without infringing on the
upstream community's autonomy.

Regards,
Nick.

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