Branch Intelligence in Bugzilla

[L. David Baron]

On Thursday 2006-07-27 14:51 -0700, Max Kanat-Alexander wrote:
> On Thu, 2006-07-27 at 11:28 -0700, L. David Baron wrote:
> > 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.
> 
> 	Hrm. So perhaps a way to note that a certain branch always appear on
> all versions would be useful? And then later you can move the fields to
> showing up only on bugs filed against 1.9. But if you'd set any values
> in the fields on old bugs, the fields would still show up there.

I'm really not sure what it is that you're suggesting, or how it would
help.  Frankly, I've never found the version field very useful -- it's
simply a snapshot of one version on which the bug is present.  I think
if bugzilla understood branches, the original reporter could choose a
version, and that version would be translated to status information on
the relevant branch, plus text in the initial comment of the bug, and
then disappear.

> > 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.
> 
> 	Well, if you just selected that it affected the trunk, by my proposal
> the system wouldn't say *anything* about the branch until you also said
> that it affected the branch.

But there would also probably need to be a way of saying that a bug does
*not* affect the branch.

-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/20060728/c4961718/attachment.sig>