vicente.botet wrote:
----- Original Message ----- From: "David Abrahams" <dave@boostpro.com> To: <boost@lists.boost.org> Sent: Sunday, February 22, 2009 1:02 AM Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
on Sat Feb 21 2009, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
Hi,
For each bug, there are really two levels of "fixed": roughly speaking, the developer considers the issue fixed when it is committed to trunk, while the user considers the issue fixed when it is commited to the release branch.
Yes, this is one place our current branching system is breaking down.
At present, the trac ticket is closed at the first gate. Unfortunately, sometimes the second gate gets forgotten. Could another state be added to the ticket lifecycle to track when it gets merged to release?
It's an excellent idea. We should also update the post-commit hook to be able to close the ticket when "fixes #xxx" shows up int the checkin comment on the release branch.
My aim is to be able to identified "fixed" tickets that are not actually released and, hopefully, to decrease them in number. Maybe there are other ways to achieve this?
I'm afraid there's no easy way. I usually just pore through the diffs between trunk and branches/release.
Currently there are the following states: new, assigned, closed, reopened. We could add * fixed_in_trunc: set when code commited in trunk branch with comment fixes #xxx * verified_in_trunc: set when the associated test pass on trunk regression tests * fixed_in_release: set when code commited in release branch with comment fixes #xxx * verified_in_release: set when the associated test pass on release regression tests
FWIW, we have good experience with "fixed, not delivered" and "fixed, delivered" states. I don't see the need for 'verified' states -- if somebody is not sure that a commit is actually fixing a bug, then he should mark the ticket as fixed only when necessary testing completes. - Volodya