Bug status transitions ~ bug 27908

Hi,

there is bug 27908, which i closed as invalid, because user did not
used latest fixed version.

AJ says: If there was a bug then it's FIXED.

Based on that, even if the user has a crash in 1.0.1 and opens _now_
a bug and one day later says "it is FIXED in 1.3.25", then it should
be marked as FIXED.

Because i noticed before, that this is handled differently, i'm
writing here about above rule, which unify that.

Regards,
W.

[Austin English]

2011/7/27  :
> Hi,
>
> there is bug 27908, which i closed as invalid, because user did not
> used latest fixed version.
>
> AJ says: If there was a bug then it's FIXED.
>
> Based on that, even if the user has a crash in 1.0.1 and opens _now_
> a bug and one day later says "it is FIXED in 1.3.25", then it should
> be marked as FIXED.
>
> Because i noticed before, that this is handled differently, i'm
> writing here about above rule, which unify that.
>
> Regards,
> W.

In the case of bug 27908, there was no release yet, and I don't think
it's unreasonable for a user to report bugs that are in the latest
release. Building from git is a time/space consuming pain for most
users. If a user reports a bug in a very old release, it's not
unreasonable to ask them to try in a newer release before looking at
the bug. If the bug was reported in old wine and fixed in newer, well,
it technically was fixed, but marking it invalid helps prevent skewing
our bug statistics (and may encourage the user to try latest
development releases before reporting bugs) :).

[Alexandre Julliard]

Austin English  writes:
> In the case of bug 27908, there was no release yet, and I don't think
> it's unreasonable for a user to report bugs that are in the latest
> release. Building from git is a time/space consuming pain for most
> users. If a user reports a bug in a very old release, it's not
> unreasonable to ask them to try in a newer release before looking at
> the bug. If the bug was reported in old wine and fixed in newer, well,
> it technically was fixed, but marking it invalid helps prevent skewing
> our bug statistics (and may encourage the user to try latest
> development releases before reporting bugs) :).

I don't see why it would skew the statistics. If the user encountered a
bug and we fixed it, it should count as a fix, no matter when the bug is
reported.

Of course if it's already fixed, it's probably because there was an
older report about it, in which case the new one should be marked
duplicate. But if it's really a bug we didn't know about that happened
to be fixed by "collateral damage", it's still a valid report and should
be marked fixed.