[Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Nick Coghlan]

On 30 May 2015 at 21:37, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 30 May 2015 21:20:56 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Given the extensive complaints about the lack of corporate
>> contribution to upstream CPython maintenance, the hostile reaction to
>> a concrete proposal for such ongoing contributions has been both
>> incredibly surprising *and* disappointing
>
> IMHO, they were not more hostile than against individuals'
> contributions of the same kind. Any patch proposal is bound to
> controversy, that's a normal aspect of the process, and one that
> contributors should usually be willing to go through.
>
> Also, when there are in rules in place, most people want to see them
> upholded, because that tends to promote fairness much more than when
> exceptions are granted all over the place. So people's reactions have
> really been understandable, if debatable.

Agreed, but it's also understandable when folks forget that things
that they're taking for granted aren't necessarily common knowledge.

In this case:
* the fact that this proposal was a suggested starting point for
ongoing contributions, not a one-and-done effort
* the fact that the rationale for the prohibition on performance
enhancements was *different* from the reason for disallowing new
features (and hence requiring a PEP for *any* new Python 2.7 feature)

For folks that already knew both those facts, this *wasn't* a
controversial suggestion. We unfortunately failed to account for the
fact that not everyone was aware of that context, and that *is* a
highly regrettable mistake.

Hence my information dumps thoughout the thread, attempting to provide
that context without committing folks to things they haven't committed
to, and without disclosing potentially confidential third party
information.

>> The offer came with one string attached: that the Python 2.7 branch be
>> opened up for performance improvements in addition to bug fixes. Since
>> maintainability was the main concern with not backporting performance
>> improvements in the first place, this seemed like a straight up win to
>> me (and presumably to other folks aware of the offer), so it never
>> even occurred to us
>> that folks might not accept "because this proposal
>> is backed by a credible offer of ongoing contributions to CPython
>> maintenance and support" as a complete answer to the question of "Why
>> accept this proposal to backport performance enhancements, and not
>> previous proposals?".
>
> You're making contribution some kind of contractual engagement. That's
> not an obvious improvement, because it has some large impacts on the
> power structure (for one, volunteers can't reasonably compete with
> contractual engagements).

We've long had a requirement that certain kinds of proposal come with
at least nominal support commitments from the folks proposing them
(e.g. adding modules to the standard library, supporting new
platforms). Institutions with a clear financial interest in a
particular problem area can certainly make such commitments more
credibly, so I agree with your concerns about the potential impact on
the power dynamics of core development.

That's one of the main benefits I see in attempting to guide sponsored
contributions towards Python 2.7, at least initially - that's in LTS
mode, so working on it is fairly uninteresting anyway, and it keeps
discussion of *new* features (and hence the overall direction of
language evolution) a community focused activity.

Cheers,
Nick.

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