[GNC-dev] verifying bug fixes - bug lifecycle - what happened to VERIFIED?

Dale Phurrough dale at hidale.com
Thu May 16 11:59:08 EDT 2019

What is the de facto process, or if written, on the transition from
RESOLVED bug -> VERIFIED bug for the Gnucash project?

My inquiry is due to a private conversation...bringing it broader.
I checked and haven't yet found a gnucash doc on this.

Personally, the bug lifecycle I'm most familiar has the person that opened
the bug, to verify the resolution of the bug. [Disclaimer: FOSS project,
can't force anyone, etc.] As a rough series of steps, I as a "responsible"
bug opener...

   1. run bugzilla queries for bugs I opened that are in the RESOLVED state
   2. spin up a Docker container, compile at the commit of their fix
   3. test that the fix resolves the issue
   4. update the bug

I can do the first three steps independent. My verification "closes the
loop" on the bug that was important enough to me to open the bug. It also
provides the community a second verification check that the fix works and
doesn't break something else. Step 4 is something that affects others in
the community.

   - If the fix/resolution "works", I prefer to shift the bug to VERIFIED.
   That gets it off my worklist/queries.
   - If the verification fails, I prefer to personally contact the person
   that RESOLVED it, shift the bug to a non-RESOLVED state, and add details to
   the bug on what failed with the fix and how to reproduce the failure.

VERIFIED is the last step of the bug lifecycle

FYI, in 2019 there were (approx queries):

   - 179 bugs resolved
   - 0 bugs verified


More information about the gnucash-devel mailing list