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

[D John Anderson]

+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