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

[Daniel (ajax) Diniz]

"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).

Right now, having the informative data in messages would be broken, as
the tokens shorter than three characters aren't indexed (and periods
split tokens), but that would be really easy to fix (we could even
include a regex to find the 'affects python x.x' comments).

So I'd like to cater for the other rule regardless of which one we
choose for selecting versions :)

perhaps-I-should-be-in-social-sciences-ly y'rs,
Daniel