[Chandler-dev] Desktop Processes wiki page and dev branch tracking issue

Bryan Stearns stearns at osafoundation.org
Thu Oct 11 16:14:26 PDT 2007


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


More information about the chandler-dev mailing list