Andrea, Thanks for your explanation! I think we can just follow the original process if the development is on a feature branch, and close the defect only when the fix is available on main trunk or a release. While if the fix is delivered directly to trunk or a release branch, we can take the lighter approach and go quickly to CLOSED status.
- Simon 2012/8/25 Andrea Pescetti <[email protected]> > On 22/08/2012 Shenfeng Liu wrote: > >> (2) I'm not sure what's the difference between the status *Verified* >> and >> *Closed*. IMO all the defects verified should finally be closed. >> > > In the old OpenOffice.org project, where the QA process was probably more > formal, the meaning were the following: > - Verified: a developer snapshot (in binary form) contains the fix > - Closed: a stable version (in binary form) contains the fix > > So in theory one should now go through all the VERIFIED issues, check them > with version 3.4.1 and set them to RESOLVED CLOSED if the fix works. > > In practice the code now has fewer complexities than it used to have (it > had dozens of "Child workspaces", or CWS, where development was done) so > it's understandable that we take a lighter approach on this too. > > Regards, > Andrea. >
