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

Brett Cannon brett at python.org
Thu Mar 26 03:40:53 CET 2009


On Wed, Mar 25, 2009 at 17:50, Daniel (ajax) Diniz <ajaksu at gmail.com> wrote:

> "Martin v. Löwis" wrote:
> >>> 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
> :)
> >
> > So do I: I only tag the versions where the bug should be fixed, or, more
> > precisely, where there is still action needed.
> >
> > So I remove a version from the list if the bug exists in that versions,
> but
> > will not be fixed there, and also remove a version if a patch has
> > been applied to that version, but still needs to be applied to other
> > versions.
>
> It seems to be a matter of favoring an operative versus an informative
> use of the tracker. I think both make sense and that consensus is
> simple in this specific case.
>
> >> 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 switch so easily. I like my rule better than Brett's - what's
> > your rule?
>
> Mine is 'be doubtful, always' :)
>
> OK, more seriously, I've been working under the operative assumption,
> more specifically using a "RFEs set to next major releases, bugs (and
> doc RFEs) for current major releases" rule that I'm pretty sure I
> learned somewhere a long time ago. But it was a rule about when things
> get fixed/addresses, not about what to set in the tracker, IIRC.
>
> I think consensus here is easy. It's possible to mark all versions in
> Brett's rule and have tooltips explaining which fixes can land in
> which versions (and we operative people would have to learn to look at
> the selected versions in a slightly different way). Or we could select
> versions in the operative way and include the data from the
> informative one in messages or in a new property (and have tooltips
> for version explaining how to learn which versions are affected).


Go with Martin's approach; less clicking.

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


More information about the Tracker-discuss mailing list