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

Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-22 05:48:32

----- 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

May be a test case reference could be added as a field of the ticket.
 
The ticket should be closed only when the release is delivered. This could be done automaticaly by the release managers, just change all verified_in_release in the current release to closed.

Vicente