[GNC-dev] verifying bug fixes - bug lifecycle - what happened to VERIFIED?
jralls at ceridwen.us
Thu May 16 14:23:32 EDT 2019
OK. Very few users set VERIFIED, but you may if you like. Most users aren't shy about reopening a bug if the expected fix doesn't work for them.
> On May 16, 2019, at 8:59 AM, Dale Phurrough via gnucash-devel <gnucash-devel at gnucash.org> wrote:
> 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
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel