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

[Aparna Kadakia]

Thank you Bryan for resurfacing this thread. Clearly even I had not  
digested the full scope of the issue in my first reading.
My comments are inline.
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.
>
Yes, a bug that is fixed in the branch should not be marked FIXED  
until it lands in trunk because QA won't be checking out branches to  
verify fixes. It's just not possible given the limited bandwidth of  
the QA team to keep track of branch builds and verifying them.

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

+1 (as reasoned above)
>
> 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".
+1
Having the "have_fix" keyword sounds like a good idea. We can prepare  
'saved searches' for bugs with the "have_fix" keyword. So people  
don't have to go thru the hassle of doing advanced queries in  
bugzilla for keyword searches.

> - 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?
Yes, duplicate bugs do get verified.

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