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
