<br><br><div class="gmail_quote">On Thu, Jan 26, 2012 at 12:33 PM, Jeff Licquia <span dir="ltr">&lt;<a href="mailto:licquia@linuxfoundation.org">licquia@linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div>anyway...</div><div>I once did a writeup on our bz process, now sorely in need of updating (it was</div><div>stolen from someone else&#39;s process, then updated - but things have changed,</div><div>and I&#39;d describe some stuff differently now - the note above is more concise)</div>

<div><br></div><div><a href="http://wiki.linuxfoundation.org/en/UsingLsbBugzilla">http://wiki.linuxfoundation.org/en/UsingLsbBugzilla</a></div><div><br></div><div>also note that there are roughly two classes of bz items: ones which tie to</div>

<div>a &quot;product&quot; (commit change to bzr, let autobuilder build product, release it)</div><div>and ones which don&#39;t.  For the latter kind there&#39;s usually nothing that maps</div><div>onto this three-step proposal.  For example &quot;update FOO on website&quot; -</div>

<div>there is normally no intermediate step in which the fix can be verified short</div><div>of it being deployed, so you could say, go straight from resolved to closed,</div><div>skipping verified...  or could leave the -&gt; closed for a different role.  not a</div>

<div>big deal, just wanted to mention.</div><div><br></div><div> </div><div>the note on rollups is a useful one.  a bug that is going to go out in a</div><div>&quot;product&quot; should be attached to a rollup; completing the release rollup</div>

<div>should involve making sure all the blockers are in &quot;verified&quot; state, then</div><div>the product ships, and all those can flip to closed, and the rollup closed</div><div>out as well.  that should in theory handle making the transitions smooth...</div>

<div><br></div><div><br></div></div>