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