+1
I liked Philippe's proposal, however after reading Bryan's comments,
I think it's a nice refinement to the original proposal.
John
On Oct 11, 2007, at 4:14 PM, Bryan Stearns wrote:
Hi Philippe,
A few comments on your branch/tracking proposal, below...
Philippe Bossut wrote:
Here's the problem:
- we want to keep track of dev branches wrt to target release so
we have an idea of what's worked on at any time
- it's unclear how to treat bugs that are fixed on branches in
Bugzilla
Proposal:
- create a "superbug" in Bugzilla for each dev branch
- mark all bugs related to that branch as "blocking" the superbug
I think it'll be rare (or should be!) that a branch be used to fix
many bugs; generally, there'll be just one (eg, "do month view"),
to avoid the snowball effect. (When that's not the case, and a
single task is broken down into many bugs, the superbug model is
normal Bugzilla practice.)
- the superbug gets a keyword "branch_node" set to it (so we can
easily find them)
- only when the branch is merged into the trunk is the superbug
marked fixed
We talked about this offline a little: I think it's definitely
right to not mark bugs fixed until they land in the trunk -
otherwise, it'll be tough for testers to figure out what to verify.
The downside here is that you can't look at bug status to see how
much work is "done" - you'd have to look for a "have_fix" keyword.
I think that's acceptable, at least for now: we can always change
that part of the plan later.
- bugs blocking a superbug can be marked fixed when fixed in the
branch, their target_release though should be something else than
"0.7.x" (since we don't know when it's going to land really and I
could pick them up by mistake when creating the release note) so
I'm proposing "0.7.future" for those. I'm not thrilled by this
idea though. Better ideas welcome (I'm trying not to create
another target milestone to park those bugs...)
I disagree with this: I don't think any bugs should be marked fixed
until they land in the trunk.
I think the idea is that you can look at the target release to see
what work is intended to be done in the current release, even
though some stuff might get rolled over into the next release if it
doesn't make the cutoff date.
Instead, I see three choices:
- leave the blocking bugs open with "have_fix".
- add another status (or resolution?) to bugzilla, "FIXPENDING" - I
don't know if this is even possible.
- close them as duplicates of the superbug, since part of verifying
closed bugs is verifying the cases described by bugs closed as
duplicates, right?
As I said above, I don't think the superbug thing will get used for
branches much, so we should do the simplest thing (open/"have_fix")
until it's proven not to work.
- symmetrically, the branch should be named with a reference to
its superbug so that one can easily check the details and status
of a branch. I'm proposing to use a human readable name and the
superbug reference, i.e. <name>_<bugnumber> for the branch name
+1
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
