Does it make sense to close all issues that are only for Python 2.7 after 2.7 has reached its end of lifetime? After all we could get rid of about 10% of all open bugs. Yesterday there are 7141 open bugs on BPO. 1832 entries have version Python 2.7 assigned. The UI doesn’t allow to filter on version Python 2.7 exclusively. I played around a bit with the CVS export. 499 bugs are just for Python 2.7. Additional tickets are for version 2.7 with 2.6, 3.0, 3.1, 3.2, 3.3 or 3rd party mixed in. I estimate another 200 ticket here. BPO doesn’t let you search or create tickets for old Python versions but tickets retain the old versions.
Should we auto-close Python 2.7 bugs in 2020?
2 Likes
I would hope they would be somehow labeled so people who find them will not think they have been fixed. But this brings up a more general question:
Is there a PEP for what happens to Python2 after official support ceases? For instance, will the issues and pull requests be purged at some point? Will the documentation and downloads be removed from python.org?
Other implementations (Jython, IronPython, PyPy …) may choose to continue to develop Python2 versions. Will the PSF prohibit them from using the Python name? If those implementations wish to continue hosting the documentation and development of a reference C-based Python2 version to compare against, what should they call it in order not to give the impression it is “official”?
BPO has a bunch of resolutions for tickets. The appropriate resolution for an auto-closed ticket is “out of date”. Naturally auto-closing will leave a comment on the ticket why the ticket was closed.
We don’t remove downloads or documentation. You can still view the official documentation for e.g. Python 2.1 or download it from python.org.
The last paragraph is about legal and trademark issues and not related to bug tracker. IANAL, please create a new thread.
I do not think they should be closed automatically. Every bug should be checket individually for 2.7 and supported 3.x versions. If it is reproduced on 3.x, it should stay open, just with different labels. If it no longer reproducible on 2.7, it should be closed with different resolution. The core developer who closes the issue is responsible for his decision.
There are also bugs which was fixed in 3.x, but the fix was not backported to 2.7 for some reasons. It is more difficult to find such issues because they can still be labelled for 2.7 and 3.x.
1 Like
This is a giant amount of work and I’m quite sure that nobody wants to do that. I would prefer to close the old Python 2-only bugs with a clear message like:
“This bug was closed automatically because it has no activity for longer than 2 years and it targets Python 2 which is no longer supported since 2020-01-01.”
Maybe add a link to a webpage which gives further details and/or explain how to ask to reopen an issue.
IMHO it’s ok to close bugs which also impact Python 3. We cannot fix all bugs, whereas most people want to reduce the number of open issues.
In Fedora, bugs affecting the current stable version are automatically closed when a new Fedora version is released. It’s easy to reopen an issue and retarget it to the latest version, which is commonly done. IMHO it helps a lot to automatically clean up inactive bugs with non responsive reporter.
If a Python2-only issue is active for less than 6 months, I suggest to leave it open and wait until it becomes inactive for at least 2 years.
3 Likes
As a user I find this behavior extremely frustrating. In a different project I gave up after being asked to verify a bug’s existence for the fourth time.
I will admit to being curious, though: How many bugs are actually fixed by a new version release when no effort was made/recorded on the bug ticket?
5 Likes
It’s a one time thing. I don’t want to auto-close bugs annually. We might consider doing another auto-close round in 15, 20 years when we drop Python 3.
1 Like
IIRC, something similar is/was/will be discussed re. the move to GitHub: it seems that the current WIP plan is to not migrate all issues to the new tracker, but add a mechanism to migrate them on demand.
Given that py2 issues are a subset of old issues, I don’t think we need to discuss them separately.
I think a quick check of issues against master probably enough as chances are the issue was fixed a while ago and who know what would need to be backported.
PRs will most likely be closed immediately because our switch to GitHub happened recently enough that any new PRs should have targeted master which was very much past 2.7 being created, so that makes any PR targeting 2.7 no longer useful to us post the 2.7 branch being shut down and turned into a tag.
I agree with closing Python 2 bugs as a one-time thing. Python 3, especially the more recent versions, is very different from Python 2 so the chances that the bug still applies are slim.
Hello, I agree with your concept closing python 2 bugs as one-time.