Should non-security 2.7 bugs be fixed?
tjreedy at udel.edu
Sun Jul 19 03:34:21 CEST 2015
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
>> 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
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
More information about the Python-list