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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/archive%40mail-archive.com
