Branch Intelligence in Bugzilla

[Max Kanat-Alexander]

        Some of us have been reading dbaron's message about
bugzilla.mozilla.org management, here:

http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/fb9c78418938bdc6/2227ccd96a042c69

        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 mozilla-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.

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Max Kanat-Alexander]

        Also:

        For searches, we could have a list of branches both on query.cgi and
colchange.cgi. On colchange.cgi, you could set which branches you'd like
to see the branch fields for. On query.cgi you could also set these, and
they'd override what you selected as defaults on colchange.cgi.

        (Just wanted to get that down while it was in my mind.)

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Jochen Wiedmann]

On 7/27/06, Max Kanat-Alexander <mkanat@...> 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)
>
>         "Fix In" would represent both the version we plan to fix it in, and the

To me that sounds very much like your original "make Bugzilla too
complex". And, although I am using branches in any of my open source
and business projects very heavily, I do not even stand the rationale.

In other words: If you do decide to put that in, please make it at
least a configurable option and, by default, omit it from the GUI. If
that should appear in any Bugzilla I am working with then the only
thing I would expect would be weeks of discussion whether/how/when/why
this should be used or whatever else.

Jochen

--
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Max Kanat-Alexander]

On Thu, 2006-07-27 at 08:37 +0200, Jochen Wiedmann wrote:
> In other words: If you do decide to put that in, please make it at
> least a configurable option and, by default, omit it from the GUI.

        Yes, I absolutely agree with you. It would not appear in the GUI unless
enabled. It would only appear in products for which you specified more
than one branch in editversions.cgi.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Robert Kaiser]

Max Kanat-Alexander schrieb:
> * 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Dave Williss]

I know at our site, we actually use the "Target Milestone" to indicate
the version a bug was fixed in, and we don't usually even set it until
it's fixed.  Occasionally we will set it if a bug is marked as a blocker
to indicate which version it's blocking.  But we find a better way to
mark bugs as blocking a release is to issue a bug with the summary
something like "Get version X.Y out the door" and make it any bugs
that would prevent the release a blocker of that bug.

So for us, "Target Milestone" is used more for historical reference than
planning.  We would much rather have a "Fixed In"

----- Original Message -----
From: "Robert Kaiser" <kairo@...>
Newsgroups: mozilla.dev.planning
To: "Max Kanat-Alexander" <mkanat@...>
Cc: <developers@...>; <dev-planning@...>
Sent: Thursday, July 27, 2006 5:15 AM
Subject: Re: Branch Intelligence in Bugzilla

> Max Kanat-Alexander schrieb:
>> * 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
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dwilliss@...>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[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

[Max Kanat-Alexander]

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?

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Max Kanat-Alexander]

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 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.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Boris Zbarsky]

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.

> 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Max Kanat-Alexander]

On Thu, 2006-07-27 at 16:59 -0500, Boris Zbarsky wrote:
> 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.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Bradley Baetz]

On 28/07/06, Max Kanat-Alexander <mkanat@...> wrote:
>         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?

Yes - branches may need approval to check in to (or, in a more
traditional model, 'released' to a particular environment). What would
be nice is if a bug could be marked as fixed-in-cvs when the fix was
in CVS, but not fixed on the branch.

Developers could then look at what bugs were open, and project
managers/etc could look at what bugs were fixed but not fixed on their
env.

>         Anybody have a better idea that wouldn't involve making the proposed
> "branch" fields more complicated?

Oh. Umm.... :)

Bradley
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Jochen Wiedmann]

On 7/27/06, Max Kanat-Alexander <mkanat@...> wrote:

> 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)
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Jochen Wiedmann]

On 7/27/06, Boris Zbarsky <bzbarsky@...> wrote:

> 100% of the time, for Mozilla.  Branch fixes require additional approvals, after
> the the trunk fix has been verified.

Which makes me wonder whether this branch thingys model is any good.

In my mind I do see this as a meta bug with several dependent bugs
(one per branch). In other words, it might possibly be sufficient to
support creating the meta bug and the dependent bugs at one go.

Jochen

--
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[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

[John P. Fisher]

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...

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

Boris Zbarsky wrote:

> 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.
>
>> 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
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=john.fisher@...>
>

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Gervase Markham]

Jochen Wiedmann wrote:
> To me that sounds very much like your original "make Bugzilla too
> complex".

It sounds a bit like it to me, too :-|

Note that Google, in their very-recently-announced hosting project, is
moving in the opposite direction - less structured fields, more tags,
and better search. While we don't have their search fu, we might want to
pause before making the Bugzilla UI even more complex, given that this
is one of the things it's often criticised for.

Gerv


-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[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.



-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>