Branch Intelligence in Bugzilla
Max Kanat-Alexander
bugzilla.mozilla.org management, here:
When reading this and discussing it with Myk and LpSolit, I finally
came to the idea that Bugzilla should understand the idea of a "branch."
Now, this idea has been proposed in the past, and I rejected it, saying
that it would make Bugzilla too complex. However, reading dbaron's
message, and thinking about my own bug list, I think it would be useful
in a lot of ways.
Here's what I'm thinking:
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)
"Fix In" would represent both the version we plan to fix it in, and the
version it was actually fixed in.
We could mark certain versions as "unreleased," so that they would show
up in the "Fix In" list, but not in the "Version" list.
More than one branch could be associated with a version, so "alpha" and
"beta" could both be considered "branches" under this system.
I think that would handle our current problems, and would make bug list
triage much more meaningful in a world with many branches.
I think this would be worthwhile as a core Bugzilla feature because
nearly every open-source and corporate user of Bugzilla has some need
for Bugzilla to understand the idea of a "branch."
(If you reply to this message from dev-planning, make sure to
CC me directly since I'm not on the list.)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Robert Kaiser
> * Fix In: (Put all branch versions here)
>
> "Fix In" would represent both the version we plan to fix it in, and the
> version it was actually fixed in.
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?
The overall idea sounds good, but mixing the target and "fixed in"
sounds a bit dangerous to me. Though I think replacing our "fixed*"
keywords (possibly even "verified*"?) with such a branch-aware field
would be really nice...
Robert Kaiser
L. David Baron
> 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.
>
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
Max Kanat-Alexander
> 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?
Max Kanat-Alexander
> 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 just trying to come up with some *ideal* way to handle the
situation that you're in, because it's actually an extremely common
situation, and I'd like to be able to deploy it generically to all users
of Bugzilla as a part of the upstream code.
> 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.
Okay, easy enough. So it might be good for Bugzilla to understand the
idea that branches are related to other branches. That is, most branches
come from the trunk, and thus anything on the trunk before "date X" is
also on the branch.
> 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.
Boris Zbarsky
> Does that actually happen that frequently, though, that something is fixed on the
> trunk but not on a branch?
100% of the time, for Mozilla. Branch fixes require additional approvals, after
the the trunk fix has been verified.
> Usually in that case I just leave a bug open, and leave a comment on it...
That gives really bad tracking of what's fixed on trunk.
-Boris
Boris Zbarsky
> Does that actually happen that frequently, though, that something is fixed on the
> trunk but not on a branch?
100% of the time, for Mozilla. Branch fixes require additional approvals, after
the the trunk fix has been verified.
> Usually in that case I just leave a bug open, and leave a comment on it...
That gives really bad tracking of what's fixed on trunk.
-Boris
Max Kanat-Alexander
> Max Kanat-Alexander wrote:
> > Does that actually happen that frequently, though, that something is fixed on the
> > trunk but not on a branch?
>
> 100% of the time, for Mozilla. Branch fixes require additional approvals, after
> the the trunk fix has been verified.
Okay, good point. So it sounds like branches also need their own
Resolution field, which can be blank. I'm not sure they also need their
own Status, though--seems like just Resolution would be enough.
Jochen Wiedmann
> 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?
Yes, of course. It's quite usual to develop a "fix" (which may of
course as well be a new feature, in other words something larger) in
the trunk and backport it later.
Jochen
--
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)
L. David Baron
> 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.
John P. Fisher
I modified a Bugzilla 2.17 vintage to include found-in and fixed-in
fields, a branch field for differing CVS branches, and cloned bugs to
keep track of single problems that occur in multiple code trees.
( i.e. the algorithm is roughly the same, but the code is separate ) It
should be noted that we have several different hardware platforms, that
have somewhat different APIs and capability/capacity.
anyway.
Its turns out that Test are the most fanatical about the clones/branches
and fixed-in requirement. They need to keep track of which fix they
tested on which hardware- just because it works on the A model doesn't
mean it works on the T model. you get the idea...
So to answer Max's question, its true all the time for us too, but
tracking testing is equally important. We don't have enough engineers to
fix everything everywhere right away. Who does?
John
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=john....@znyx.com>
>
Benton, Kevin
> > 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
> mean that some organizations fix the branches at a different time than
> they fix the trunk?
>
to
> actually happen that frequently, though, that something is fixed on
the
open,
> and leave a comment on it...
>
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.
Bill Davidsen
> I hope you don't mind a lurker poking in 2cents worth...
> I modified a Bugzilla 2.17 vintage to include found-in and fixed-in
> fields, a branch field for differing CVS branches, and cloned bugs to
> keep track of single problems that occur in multiple code trees.
> ( i.e. the algorithm is roughly the same, but the code is separate ) It
> should be noted that we have several different hardware platforms, that
> have somewhat different APIs and capability/capacity.
> anyway.
> Its turns out that Test are the most fanatical about the clones/branches
> and fixed-in requirement. They need to keep track of which fix they
> tested on which hardware- just because it works on the A model doesn't
> mean it works on the T model. you get the idea...
Is there any thought to move this back into mainstream? It sounds useful
for just the reasons you mention.
--
Bill Davidsen <davi...@tmr.com>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
John P. Fisher
gave up. A better developer with more time could have done it, but not
I. So I am not applying any patches from the main trunk of code and my
tree is hopelessly divergent. sorry, I wish it weren't so.
Bugzilla been very very good to me, and thanks for all the years of
development time.
But I think my next major effort, if it rises to the top of my project
pile, is a php rip-off of Bugzilla concepts. I would be interested in
making a slimmer, highly customizable version aimed at commercial
development shops like mine. Bugzilla is already covering other types of
development very well, and there's no point in reinventing that wheel.
PS I've been saying this for 2 years so no one is holding his breath. ;>)
John