Branch Intelligence in Bugzilla

[Benton, Kevin]

> On Thu, 2006-07-27 at 12:15 +0200, Robert Kaiser wrote:
> > How do we make sure then that bugs that had been targeted (planned)
to
> > be fixed in that release and actually didn't make it are not
mistakenly
> > marked as fixed when the release is actually out?
> 
> 	Because bugs get marked as FIXED when they're checked into CVS
(or
> whatever SCM you're using), not when a release comes out. So at the
time
> that somebody marks the bug as FIXED...oh, I see what you mean--do you
> mean that some organizations fix the branches at a different time than
> they fix the trunk?
> 
> 	In that case you're probably right that it would be advantageous
to
> note that something has actually *been* fixed on a branch. Does that
> actually happen that frequently, though, that something is fixed on
the
> trunk but not on a branch? Usually in that case I just leave a bug
open,
> and leave a comment on it...
> 
> 	Anybody have a better idea that wouldn't involve making the
proposed
> "branch" fields more complicated?

Target Milestone is used here to reflect the version we *want* an issue
fixed in, and commitment (new field) is used to reflect when an issue
must be fixed.  RESOLVED is when an issue passes development's testing.
VERIFIED is when Validation (Q/A) has completed testing to the point
where they are confident that the patch can be applied to the trunk
without negative impact.  CLOSED is when the fix is released to our
customers.

We also have a requirement that each effected branch has a bug filed
because each will require its own testing, so we don't have a problem
with version cross-over.  When a bug hits a CLOSED state here, it has a
traceable history with our customized fixed_in_rev and found_in_rev
fields telling us where it was fixed and found (found meaning the
earliest revision the issue was seen in).  When it turns out that we're
just entering Errata, we also have an errata_to_rev field.  All three of
these fields key off a single version table for the product.  For a bug
to be filed, a found_in_rev is required.  For a bug to enter the
RESOLVED state, either fixed_in_rev or errata_to_rev must be valid.  By
default, these fields are 0 which is auto-replaced with "N/A".  If a bug
goes to the REOPENED state, the fixed_in_rev and/or errata_to_rev fields
are automatically cleared.

---
Kevin Benton
Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator
AMD - ECSD Software Validation and Tools
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.