Question - Bug Triage for 3.4 & 3.5
Hi, As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13. Number of issues 3.4: 1530 issues 3.5: 1901 issues But some issues are not related to the security. Could we update these issues (non-security) to 3.6/3.7 & 3.8? Cheers, Stéphane -- Stéphane Wirtel - https://wirtel.be - @matrixise
After discussion with Victor, my proposal will generate noise with the ML, maybe for nothing. On 02/20, Stephane Wirtel wrote:
Hi,
As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13.
Number of issues
3.4: 1530 issues 3.5: 1901 issues
But some issues are not related to the security.
Could we update these issues (non-security) to 3.6/3.7 & 3.8?
Cheers,
Stéphane
-- Stéphane Wirtel - https://wirtel.be - @matrixise _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stephane%40wirtel.be
-- Stéphane Wirtel - https://wirtel.be - @matrixise
On 20Feb.2019 0711, Stephane Wirtel wrote:
After discussion with Victor, my proposal will generate noise with the ML, maybe for nothing.
On 02/20, Stephane Wirtel wrote:
Hi,
As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13.
Number of issues
3.4: 1530 issues 3.5: 1901 issues
But some issues are not related to the security.
Could we update these issues (non-security) to 3.6/3.7 & 3.8?
Cheers,
Stéphane
It'll make same noise, sure, but if we schedule a bulk close of issues that have not been touched since 3.6 was released then at least it'll be easy to "mark all as read". And searching for current issues will become easier. I'm always in favor of cleaning up inactionable bugs (as much as I'm in favor of keeping actionable-but-low-priority bugs open, which causes quite a few conflicts at work...) That said, maybe it makes sense to wait until 2.7's EOL and do them all at once? Cheers, Steve
Hi Steve, I reply on the mailing list On 02/20, Steve Dower wrote:
It'll make same noise, sure, but if we schedule a bulk close of issues that have not been touched since 3.6 was released then at least it'll be easy to "mark all as read". And searching for current issues will become easier. As Serhyi proposed, a one by one could be interesting, to be sure we "migrate" the right issue to the right version.
I'm always in favor of cleaning up inactionable bugs (as much as I'm in favor of keeping actionable-but-low-priority bugs open, which causes quite a few conflicts at work...)
That said, maybe it makes sense to wait until 2.7's EOL and do them all at once? I have already started with some issues.
-- Stéphane Wirtel - https://wirtel.be - @matrixise
20.02.19 17:01, Stephane Wirtel пише:
As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13.
Number of issues
3.4: 1530 issues 3.5: 1901 issues
But some issues are not related to the security.
Could we update these issues (non-security) to 3.6/3.7 & 3.8?
I am against a mass changing the status of issue, since this will generate an enormous amount of noise (to me at least). But you are free to update issues one by one if you can to do some progress with them.
I am against a mass changing the status of issue, since this will generate an enormous amount of noise (to me at least). But you are free to update issues one by one if you can to do some progress with them. Sure, I don't want to update them massively, just one by one. But I prefer to ask before this kind of operation.
-- Stéphane Wirtel - https://wirtel.be - @matrixise
Hi, If Python 3.4 was the current version when a bug was reported, I would expect the version field of the bug set to Python 3.4. Maybe the bug has been fixed in the meanwhile, maybe not. Closing all bugs affected to 3.4 is a risk of loosing useful information on real bugs: closed bugs are ignored by default in "Search" operation. Changing the version field: well, I don't think that it's useful. I usually ignore this field. And it would send like 3000 emails... I don't see the point. It's not uncommon that I fix bugs which 5 years old if not longer. Sometimes, I decide to look at all bugs of a specific module. And most of old bugs are still relevant nowadays. Sometimes, closing the bug as WONTFIX is the right answer, but it can only be done on a case by case basis. Note: Same rationale for Python 3.5, Python 2.6, or another other old Python version ;-) Bug triage is hard and requires plenty of time :-) Victor Le mer. 20 févr. 2019 à 16:05, Stephane Wirtel <stephane@wirtel.be> a écrit :
Hi,
As you know, Python 3.4 and 3.5 are in security mode and the EOL for these versions are respectively 2019-03-16 and 2020-09-13.
Number of issues
3.4: 1530 issues 3.5: 1901 issues
But some issues are not related to the security.
Could we update these issues (non-security) to 3.6/3.7 & 3.8?
Cheers,
Stéphane
-- Stéphane Wirtel - https://wirtel.be - @matrixise _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
-- Night gathers, and now my watch begins. It shall not end until my death.
On 20/02/2019 18:58, Victor Stinner wrote:
If Python 3.4 was the current version when a bug was reported, I would expect the version field of the bug set to Python 3.4. Maybe the bug has been fixed in the meanwhile, maybe not. Closing all bugs affected to 3.4 is a risk of loosing useful information on real bugs: closed bugs are ignored by default in "Search" operation.
Short: add version 3.X when it is discovered in "latest branch" versus issues reported against a "binary packaged" version. Maybe the instructions re: setting version (for new issues) should be to leave it blank (especially if it is still valid on the latest (e.g., 3.X rather than official numbered branch) or only indicate the branches that will be considered for a fix). Where "version" could be useful would be when someone finds something in a "binary" release at say level 3.6, while testing shows it works fine on 3.7 (or 3.8-alpha). In other words, I see little value in a bug/issue reported when, e.g., 3.4 was fully supported (or better becoming the latest branch comparable to labeling as 3.8 today). Maybe having a label "3.X" that just goes with the flow - in addition to 3.4 - (I am thinking maybe it is not bad to know it was first reported against 3.4, but does that also mean it wasn't there at 3.3?)
Changing the version field: well, I don't think that it's useful. I usually ignore this field. And it would send like 3000 emails... I don't see the point.
It's not uncommon that I fix bugs which 5 years old if not longer. Sometimes, I decide to look at all bugs of a specific module. And most of old bugs are still relevant nowadays. Sometimes, closing the bug as WONTFIX is the right answer, but it can only be done on a case by case basis.
Note: Same rationale for Python 3.5, Python 2.6, or another other old Python version ;-)
Bug triage is hard and requires plenty of time :-)
Again, if early on, an issue could (also) be flagged as 3.X - this may make it easier to track 'ancient' bugs - and automate keeping them in sight.
participants (5)
-
Michael -
Serhiy Storchaka -
Stephane Wirtel -
Steve Dower -
Victor Stinner