[python-committers] Updated schedule for Python 3.4

[Nick Coghlan]

On 17 Jan 2014 12:03, "Kristján Valur Jónsson" <kristjan at ccpgames.com>
wrote:
>
> I never got the impression that this was a matter of funding, Nick.
>
> And while I completely understand that core developers enjoy working in 3
much more, it was decided to not accept any improvements for a +2.7 version
even from those that would do so voluntarily.  This could have be done
without making any commitment to release a 2.8 at any point.

Doing that on the core infrastructure requires core developer *time* in
order to review the patches. We made it crystal clear we weren't interested
in providing that for free, and nobody ever even asked about the
possibility of *paid* development to create a Python 2.8.

> This is why I drew the comparison.  There are barriers put in place to
try to achieve a social engineering result.

The only barrier was the core development team deciding not to proceed with
2.x feature development for free any more after the parallel 2.6 and 2.7
releases. The question of paid development has never been discussed. It's
only come up now because we're almost two releases into Python 3 only
development and commercial Python 2 users are realising there is stuff
there that they want that is technically backwards compatible with Python 2.

That means that anyone that wants a Python 2.8 release either needs to fund
the development infrastructure for a fork that doesn't involve the existing
core development team, or else come to a deal with enough core developers
that Guido can be persuaded to approve a "bought & paid for" 2.8 release.

However, given the fact that most interesting backwards compatible changes
can already be backported via PyPI, it's highly unlikely that anyone will
put up that kind of money. Stackless 2.8 is the sole exception because you
*already* have the infrastructure and community in place to maintain a
CPython 2 fork, so backporting a few additional changes from CPython 3
really doesn't make a big difference to that workload.

Cheers,
Nick.

>
>
>
> K
>
>
>
> From: Nick Coghlan [mailto:ncoghlan at gmail.com]
> Sent: Friday, January 17, 2014 7:51
> To: Kristján Valur Jónsson
> Cc: Matthias Klose; python-committers; Martin v. Löwis
>
> Subject: Re: [python-committers] Updated schedule for Python 3.4
>
>
>
>
> On 17 Jan 2014 01:02, "Kristján Valur Jónsson" <kristjan at ccpgames.com>
wrote:
> >
> > The hope is that by not adding features to 2.x, people will flock
around 3.x en masse :)
>
> Very few of us think that way - it's that we think Python 3 is a better
language in most ways, and it is certainly much easier and more pleasant to
work on, which matters a great deal for something many of us are doing as a
side project outside work hours. I personally get very annoyed by snide
remarks like this suggesting that four years of parallel feature
development and eight years of parallel maintenance on a volunteer driven
project *aren't enough*.
>
> Would you have preferred a Gnome or KDE style transition where the
parallel development periods were measured in months rather than years?
>
> Open source projects are innately engineering driven, and thus vastly
less tolerant of long term technical debt than commercial enterprises that
can offer additional financial incentives to tolerate working with old code
for backwards compatibility reasons. That's *why* a company like Red Hat
can continue to support Python 2.7 out to 2023+, even though upstream
community support will end in 2015 - people don't maintain and support old
platforms like RHEL3 for fun, we do it because we get *paid*.
>
> CCP could have stepped in at any time and proposed funding (or organising
funding for) a full Python 2.8 release after it became clear that
python-dev wasn't going to do it voluntarily, but they, like every other
commercial entity, realised doing so was likely not to be cost effective
given the preferences of upstream and the extended life cycle of 2.7. It
sounds like they may be changing their mind as 2015 nears and the idea of
Stackless 2.8 is considered, but that's exactly the way open source
*should* work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140117/88580e15/attachment.html>