[Python-Dev] Question - Bug Triage for 3.4 & 3.5

[Michael]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190221/788671a1/attachment.sig>