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

[Philippe Bossut]

Hi,

Thanks all for the comments, I really appreciate.

I agree with the confusion that will result in marking "fixed" bugs that 
are fixed on a branch only. I didn't like my own proposal that much to 
be honest which is why I started talking off line about it and encourage 
people to pipe in. Thanks for doing that Bryan :)

I amended the wiki with the "don't mark fixed but use havefix" proposal:
     http://chandlerproject.org/Developers/DesktopReleaseProcess#Bugzilla

Cheers,
- Philippe

Aparna Kadakia wrote:
> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev