[lsb-discuss] Bugzilla process: RESOLVED/FIXED vs. VERIFIED vs. CLOSED

Wichmann, Mats D mats.d.wichmann at intel.com
Thu Jan 26 19:45:19 UTC 2012

On Thu, Jan 26, 2012 at 12:33 PM, Jeff Licquia
<licquia at linuxfoundation.org>wrote:

> Mats was discussing in IRC how we got a duplicate bug filed for
> something we've fixed (bug 3204, with bug 3312 as the dup).  We talked
> about how the procedure used to be that we RESOLVED bugs on commit,
> VERIFIED them after testing that the bug was fixed in a build, and
> CLOSED them once the bug made it into a release.
> This was long ago; we've since gotten out of the habit, and some 2500 of
> the bugs are "RESOLVED FIXED".
> It seems like a good idea to me to do something like this again.  As one
> variation (suggested by Denis), perhaps we might skip the VERIFIED step,
> since we generally test the bug before setting RESOLVED anyway, and
> getting someone else to go back and check on the bug afterwards might be
> difficult.  Knowing a bug is in the hands of users with CLOSED vs.
> RESOLVED is still useful information.
> If we decided to do this, we'd have to deal with the 2500 bugs in
> Bugzilla now.  I'd propose we set all of them to CLOSED except for bugs
> attached to an open rollup.  This may cause a few to be missed, but they
> can be re-opened or re-filed as we find them.

well, we know of a specific one that is resolved, but not shipped... maybe
we can use
as a test case.

I once did a writeup on our bz process, now sorely in need of updating (it
stolen from someone else's process, then updated - but things have changed,
and I'd describe some stuff differently now - the note above is more


also note that there are roughly two classes of bz items: ones which tie to
a "product" (commit change to bzr, let autobuilder build product, release
and ones which don't.  For the latter kind there's usually nothing that maps
onto this three-step proposal.  For example "update FOO on website" -
there is normally no intermediate step in which the fix can be verified
of it being deployed, so you could say, go straight from resolved to closed,
skipping verified...  or could leave the -> closed for a different role.
 not a
big deal, just wanted to mention.

the note on rollups is a useful one.  a bug that is going to go out in a
"product" should be attached to a rollup; completing the release rollup
should involve making sure all the blockers are in "verified" state, then
the product ships, and all those can flip to closed, and the rollup closed
out as well.  that should in theory handle making the transitions smooth...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20120126/35484797/attachment.html>

More information about the lsb-discuss mailing list