Branch Intelligence in Bugzilla

[L. David Baron]

On Wednesday 2006-07-26 18:00 -0700, Max Kanat-Alexander wrote:
> 	1) Make the Version field a multi-select.
> 	2) Associate each Version with a "Branch". For example, 1.8.1, 
>            1.8.2, and 1.8.3 would all be associated with the "1.8
>            Branch."
> 	3) For each affected branch, there would be two fields that 
>            would appear on a bug:
> 
> 		* Desire: ---, Unwanted, Would Take, Wanted, Required
> 		  Where "Required" would replace our current blocking 
> 		  flags.
> 		
> 		* Fix In: (Put all branch versions here)

There are things where having Bugzilla be able to branch the status of
bugs would be useful.  However, I don't think this solves the triage
problem, because we want to start triage for a release long before
there's a branch associated with it.  For example, we're starting triage
for the 1.9 cycle around now, but it's not going to branch for more than
6 months from now.  So we want a triage concept for it now, but we don't
want to make all developers have to mark everything as fixed-on-trunk
*and* fixed-for-1.9 for the next six months.  I think these are two
separate problems.

Branching bug status simultaneously with cvs status could be useful,
although I'm not sure the complexity is worth it.  The biggest thing it
could help with is that doing bugzilla queries to determine which bugs
are fixed on a branch with our current keyword system can be very
difficult because the 'fixed1.8' keyword only appears on bugs fixed on
the branch *after* the branch separated from the trunk.  If we had the
ability to have branch statuses for bugs we'd essentially want to copy
trunk status to branch status at the branch point.

However, the complexity comes from the requirement for unknown status on
other branches.  If a bug is filed against the trunk, it might be a
regression since an already-existing branch branched, or it might be an
old bug that is also present on the branch.  There could be significant
confusion if the bug system automatically assumed either default, so I
suspect an unknown status might be needed.

-David

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20060727/635fce22/attachment.sig>