+1 There is a similar situation with some JIRA systems that I work on. VERIFIED is a nice condition. My understanding is that RESOLVED means that there is a resolution, with FIXED meaning it has been applied, with VERIFIED needed to be satisfied that the issue can be closed. There is still the case of whether it is verified in the build of a release candidate, and that takes a little more to differentiate.
- Dennis -----Original Message----- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Saturday, January 14, 2012 14:38 To: ooo-dev@incubator.apache.org Subject: Re: Java 7 and Apache OpenOffice On 13/01/2012 Rob Weir wrote: > On Thu, Jan 12, 2012 at 6:24 PM, Andrea Pescetti wrote: >> Wasn't the cycle something like the following? >> - Developer thinks the bug is fixed and marks issue as RESOLVED FIXED. >> - QA engineer sets to VERIFIED, then to CLOSED. ... > The value of having a QA engineer test a bug fix is they also "test > around" the fix, to make sure related areas are not broken. If we > want CRT, then maybe it is a good thing if the person doing the review > is not the same person who did the commit? Sure, but the review (by someone else than the developer) would be the step from RESOLVED FIXED to VERIFIED. When Ariel fixes something, the issue status should change to something different than STARTED (i.e., to RESOLVED FIXED), otherwise there will be no way for QA volunteers to find the "RESOLVED FIXED" issues and verify that they have actually been fixed properly. At least this was my understanding of the VERIFIED status in Bugzilla. Regards, Andrea.
