Should non-security 2.7 bugs be fixed?

[Terry Reedy]

On 7/18/2015 8:27 PM, Mark Lawrence wrote:
> On 19/07/2015 00:36, Terry Reedy wrote:
>> I asked the following as an off-topic aside in a reply on another
>> thread. I got one response which presented a point I had not considered.
>>   I would like more viewpoints from 2.7 users.
>>
>> Background: each x.y.0 release normally gets up to 2 years of bugfixes,
>> until x.(y+1).0 is released.  For 2.7, released summer 2010, the bugfix
>> period was initially extended to 5 years, ending about now.  At the
>> spring pycon last year, the period was extended to 10 years, with an
>> emphasis on security and build fixed.  My general question is what other
>> fixes should be made?  Some specific forms of this question are the
>> following.
>>
>> If the vast majority of Python programmers are focused on 2.7, why are
>> volunteers to help fix 2.7 bugs so scarce?
>>
>> Does they all consider it perfect (or sufficient) as is?
>>
>> Should the core developers who do not personally use 2.7 stop
>> backporting, because no one cares if they do?
>>
>
> Programmers don't much like doing maintainance work when they're paid to
> do it, so why would they volunteer to do it?

Right.  So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x 
core developer reviews and edits the patch until it is ready to commit, 
why should either of them volunteer to do a 2.7 backport that they will 
not use?

I am suggesting that if there are 10x as many 2.7only programmers as 
3.xonly programmers, and none of the 2.7 programmers is willing to do 
the backport *of an already accepted patch*, then maybe it should not be 
done at all.

> Then even if you do the
> work to fix *ANY* bug there is no guarantee that it gets committed.

I am discussing the situation where there *is* a near guarantee (if the 
backport works and does not break anything and has not been so heavily 
revised as to require a separate review).

-- 
Terry Jan Reedy