On Jun 22, 2021, at 18:35, Irit Katriel via Python-Dev <python-dev@python.org> 
wrote:
> On Tue, Jun 22, 2021 at 11:22 PM Terry Reedy <tjre...@udel.edu> wrote:
>> With 2.x gone and a backport flow, essentially all issues are for main, 
>> so leave version tags off the issue (and eliminate the need to update 
>> them!).
> For enhancement requests I agree we probably don't need to keep updating the 
> version (though it might be useful to know which version the user was looking 
> at when coming up with the suggestion).
> 
> But I think for a bug report it's useful to know the most recent version on 
> which the bug was reproduced.
> A large part of triage work is to check whether a bug report is still 
> relevant. If you see "version 3.5" then it makes sense to check on a current 
> version and either update the issue or close it.  

I think this points out a problem with our current bug system and one that it 
would be good to try to resolve in migrating to a new system: that is, the 
ambiguity of the "version" metadata in an issue. Today, that list of versions 
is used in at least three different ways: 1. to document in what Python 
versions the issue is present; 2. to document in what Python versions the issue 
should be fixed, 3. to document in what versions the issue was fixed. In many, 
probably most, cases, the "version" field of a particular issue is used in both 
ways. When the issue is opened, the version is often set to the versions 
affected. Then at various stages in its lifecycle, the issue's version field 
will generally be changed to (possibly) reflect the candidate versions for 
potential fixes (based on current policy) and later (possibly) to the versions 
for which a fix was actually merged. The various sets  of versions are useful 
information for different purposes. It would be good to try to find a way 
 to retain both, i.e. something like "affected versions", "targeted versions", 
and "fixed versions". In any case, resolving the current ambiguity would be 
good and could also save triage and housekeeping work.

--
  Ned Deily
  n...@python.org -- []

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YXDKYWE7IPXSPOV7EY2RCAPSHE27CE4I/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to