5 years old python bug?

Found a python bug while debugging a piece of misbehaving code on raspberry pi:
pi@raspberrypi:~ $ uname -a; python3 --version
Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux
Python 3.7.3

Quick search through python bugs confirms the issue:
https://bugs.python.org/issue28215

Being a vocal python promoter and seeing a problem that has been around for almost five years without having been addressed piqued my curiosity. What is the process for determining the severity/priority of a reported problem, and who and how decides whether or not a problem should be fixed?

Python 2.7 has been out of support for some time now; if you can reproduce this with a supported version (3.7 or later, I think), it would be worth continuing the report. It may have been fixed already :slight_smile:

1 Like

Sorry that was a typo. I am running python3:
pi@raspberrypi:~ $ python3 --version
Python 3.7.3
Note that the bug is still open.

It is quite common for old bug reports in open source projects to remain open even when the bug is no longer present; this happens when the bug is fixed as a side effect of other changes, and the person making those changes is not aware that they are fixing the bug!

If you can reproduce the bug with 3.7.10, then it would be quite useful to mention that on the issue.

Yeah, I understand that there is always a chance something got fixed. But what I am asking about is the process, not whether or not something may have directly or indirectly affected a reported problem (as of today).
Wearing my project management hat, I am simply curious to understand a maintenance model (process) that apparently has room for a reported bug to stay unfixed for five years. It’s really just to satisfy my intellectual curiosity, and perhaps to add a mental note as to what steps to avoid in my own job.

On the one hand you have a project with around 7,500 open bugs, 1,500 open PRs, and new 50 new bugs every week. On the other hand there are a couple of dozen volunteers who spend some of their free time on the same project. The amount of open tickets and PRs is constantly increasing.

The solution obvious is: All it takes is a sufficiently large team so the team can handle all incoming tasks and reduce the backlog slowly.

3 Likes

Thanks. That (7500;1500;50;etc.) is the piece of information I missed and needed. Sounds truly overwhelming.
On top of that, the bug in question feels like a non-trivial, likely compiler-dependent issue (only on ARM7 not x86), plus uncommon programming domain (CAN), so it all makes perfect sense now.

1 Like

If you’re interested in one of the more extreme examples of the phenomenon that @tiran talked about, check out the bug tracker for Firefox. Just be sure you are sitting down.

1 Like

How many Netscape Navigator bugs are left? :sweat_smile:

Update:
The oldest open bug on BPO is almost 20 years old. The bpo numbers are not in chronological order. We migrated them from SourceForge about 14, 15 years ago.

2 Likes

Netscape Navigator! :smile: #blastfromthepast

1 Like