[wtp-dev] clarification and documentation of bug "verification"

[David M Williams <david_williams@xxxxxxxxxx>]

Thanks everyone for the help and questions
on the verification process. 

Cameron,  I agree, in most cases
where the orignator==owner those can be left to the owner to move to verify
(as many are "notes to self"). 

Ian, I think fine to mark a bug as verified
against 1.5.x tests, even if opened on 1.0.x stream. It's most helpful
to say just that in the bug entry when marking as verified, but in terms
of prioritizing work, I don't think its that constructive to verify twice,
and the forward-most stream is the most important. 

I have captured some of the recent discussion
about verification in our workflow document. Feel free to improve it! 

http://wiki.eclipse.org/index.php?title=WTP_Bugs%2C_Workflow_and_Conventions


The meaning and methods of verification
 
FIXED to VERIFIED
The ideal, preferred workflow is for the originator to
verify a bug is fixed shortly after its introduced into a build. Ideally
the build ID (or at least approximate date of build)will be included in
the verification note. 
For old bugs, opened on previous releases, verification
normally means "works on current release" unless otherwise noted
(that is the previous release may not be fixed and may never be fixed ...
unless otherwise noted). 
The component or project leads have the discretion to
mark a bug as "closed" if it has been in the fixed state for
a very long time (such as 6 months) so it can pretty clearly be assumed
fixed. Naturally, the originator can re-open (or, open a new bug). 
DUP to VERIFIED
verifying a "duped" bug means the originator
is simply agreeing that its a valid dup ... not that its necessarily fixed.
The originator should be added automatically to the CC list of the dup,
and they are welcome to verify that once its marked as fixed. 
INVALID or WORKSFORME to VERIFIED
the originator is simply signifying they see the point
and agree. If the originator does not agree or does not see the point,
typically some polite discussion can be carried on in the bugzilla entry
without necessarily re-opening. 
LATER or REMIND
while these are (unfortunately) sitting in a "resolved"
state ... they are resolved just temporarily and it is not meaningful to
mark them as "verified". The component or project leads have
the discretion to mark a 'remind' bug as "closed" if it has been
in the 'remind' state for a very long time (such as 6 months) so it can
pretty clearly be assumed no answer is coming and must not still be a problem.
Naturally, the originator can re-open (or, open a new bug). 
VERIFIED to CLOSED
the typical workflow is for the component lead (or project
lead, or QA Contact) to move a bug from a 'verified' state to the 'closed'
state and simply signifies they agree the bug has gone through a valid
workflow, or that the bug entry is no longer helpful, constructive, or
needed.