commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: Bugzilla RESOLVED vs CLOSED
Date Thu, 28 Jul 2005 12:27:58 GMT
> RESOLVED
>      A resolution has been taken, and it is awaiting verification by QA.
>      From here bugs are either re-opened and become REOPENED, are marked
>      VERIFIED, or are closed for good and marked CLOSED.
> VERIFIED
>      QA has looked at the bug and the resolution and agrees that the
>      appropriate resolution has been taken. Bugs remain in this state
>      until the product they were reported against actually ships, at
>      which point they become CLOSED.
> CLOSED
>      The bug is considered dead, the resolution is correct. Any zombie
>      bugs who choose to walk the earth again must do so by becoming
>      REOPENED.

FYI, the general concensus with the bug tracking software that I have
used (to name one example: the Apache Infrastructure JIRA) is that
once the developers think they have fixed the bug/implemented the
change, they set the bug/CR to RESOLVED. Then the person that made the
entry (for open source projects anyway) verifies that the bug is no
longer there/the change has been correctly implemented. He/she then
sets the status to VERIFIED (if supported by the bug tracking system)
or to some other status if the solution is not (yet) appropriate. If
the status is VERIFIED, the developers then can CLOSE the bug.
Likewise, for regressions, the bug than can be REOPENED etc.
This way, a large part of the release notes can be created fully
automatically by entering every bug, change request, improvement,
feature request into the bug tracking software (even if found and
immediately fixed by a developer).

regards,
Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message