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

[Dale Phurrough]

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
https://www.bugzilla.org/docs/4.4/en/html/lifecycle.html

FYI, in 2019 there were (approx queries):

   - 179 bugs resolved
   https://bugs.gnucash.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&chfield=bug_status&chfieldfrom=2019-01-01&chfieldto=Now&chfieldvalue=RESOLVED&list_id=4164&product=GnuCash&query_format=advanced
   - 0 bugs verified
   https://bugs.gnucash.org/buglist.cgi?bug_status=VERIFIED&chfield=bug_status&chfieldfrom=2019-01-01&chfieldto=Now&chfieldvalue=VERIFIED&list_id=4166&product=GnuCash&query_format=advanced

--Dale