[Chandler-dev] Desktop Processes wiki page and dev branch tracking
pbossut at osafoundation.org
Fri Oct 12 11:42:13 PDT 2007
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:
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
>>> - 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".
> 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
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "chandler-dev" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev