Should non-security 2.7 bugs be fixed?

[Devin Jeanpierre]

Considering CPython is officially accepting performance improvements
to 2.7, surely bug fixes are also allowed?

I have contributed both performance improvements and bug fixes to 2.7.
In my experience, the problem is not the lack of contributors, it's
the lack of code reviewers.

I think this is something everyone should care about. The really great
thing about working on a project like Python is that not only do you
help the programmers who use Python, but also the users who use the
software that those programmers create. Python 2.7 is important in the
software ecosystem of the world. Fixing bugs and making performance
improvements can sometimes significantly help the >1B people who use
the software written in Python 2.7.

-- Devin

On Sat, Jul 18, 2015 at 4:36 PM, Terry Reedy <tjreedy at udel.edu> 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?
>
> --
> Terry Jan Reedy
>
> --
> https://mail.python.org/mailman/listinfo/python-list