[Tracker-discuss] type field, specifically 'crash', and proper setting of 'versions'

Brett Cannon brett at python.org
Wed Mar 25 03:24:25 CET 2009


On Tue, Mar 24, 2009 at 17:17, Daniel (ajax) Diniz <ajaksu at gmail.com> wrote:

> Brett Cannon wrote:
> >> Also, what "should" be selected in the versions field?  All versions in
> >> which the bug appears?  Only versions in which the bug might get
> >> fixed?  The version in which it was reported plus any later versions
> >> in which it is still broken?
> >
> > Any version it is known to be broken in. So if it was reported in 2.5 and
> it
> > still broken in trunk then 2.5, 2.6, and 2.7 should all be flagged. It
> lets
> > people who are using old versions find out what they might have to watch
> out
> > for since we are not about to fix anything for 2.5 that is not
> > security-related.
>
> Oopsie, I've applied a different rule to a couple of hundred of issues :)
>
> I'll use this rule from now on and eventually fix the wrong changes.
> IIRC, my wrong interpretation is somewhat widespread, so it might be
> interesting to add help/descriptions to the versions input.
>

Don't worry about this too much. Were you just resetting the version to the
latest one if you found out the bug still existed?


>
> Some doubts:
>  For a bug filled against e.g. 2.4 that was confirmed then but not
> yet in any new versions, should we add current versions to denote they
> need checking?


No. Only update the version if it has been confirmed. Having not set acts as
a flag that it has not been not been confirmed for trunk.


>
>  For bugs filled against e.g. 2.5 that were never confirmed, should
> we add the current version? And should we try to verify it for the old
> one?


Just worry about the current version.


>
>  For bugs that were confirmed for e.g. 2.3 but don't have that
> version set, should we be able to add it?


If it was confirmed you can add it if you want.

The really critical thing here is to only set it on version where the bug
has been verified. That way it is easy to tell when it is a known issue
still and one does not need to check again.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090324/60af21b1/attachment.htm>


More information about the Tracker-discuss mailing list