Re: [boost] Trac tickets: fixed in trunk vs. fixed in release

Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-02-22 10:18:06

vicente.botet wrote:

> ----- Original Message -----
> From: "David Abrahams" <dave_at_[hidden]>
> To: <boost_at_[hidden]>
> 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