[Dev] On bug resolutions

[Lisa Dusseault]

On Sep 10, 2004, at 9:40 AM, Heikki Toivonen wrote:

> I've seen some confusion over bug resolutions, so I thought I'd write 
> how I interpret them:
>
> FIXED - The bug was fixed and you can actually point to the checkin or 
> other action that fixed it.
>
> WORKSFORME - A miracle happened. It started working, but you can't 
> figure out for sure what fixed it.
Or it can't be reproduced -- person A entered the bug, person B just 
can't reproduce it.  If others can still reproduce it of course the bug 
would be reopened but many unreproducible bugs actually do stay closed.

>
> LATER - Should not be used. Set target milestone "Future" instead. The 
> reason is that a bug that is marked LATER is basically never seen 
> again and gets lost (the default query values never show it and people 
> never remember to query for it).
>
> WONTFIX - There is a reason why this bug is not going to be fixed, and 
> why it should never actually be fixed even if somebody else thought it 
> might be a good idea. The wontfix reason should clearly state why it 
> should never be done. If it is something we won't be doing now, but 
> maybe in a year or two, set target milestone "Future".
Mostly I agree, but for feature requests that we're not including in 
the plan for the next year or so, my personal preference is not to have 
a pile of those in bugzilla -- it can get tiresome to have to deal with 
them again and again every time we review the future bugs.  E.g. 
yesterday we resolved a few things WONTFIX because they were feature 
requests that aren't in the feature plan anywhere in the next year or 
even two.

Speaking of feature or design change requests, should we have some kind 
of convention to mark them as such for faster review?  E.g. prefix the 
title of each "bug" with DCR if it's actually not a bug, but a request 
for a brand-new feature, or a request to change behavior that is 
working as designed but the requestor would prefer another design.


>
> INVALID - The bug does not make sense, or there was some 
> misunderstanding. Either it was invalid already when it was failed, or 
> things changed so that it became invalid. An example of the latter 
> happening is for example a bug in some 3rd party library which becomes 
> invalid if we remove the 3rd party library from the build.
Does this include "pilot error"?

>
> -- 
>   Heikki Toivonen
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev