Trac tickets: fixed in trunk vs. fixed in release
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. 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? 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? Regards, -Steve
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. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
----- 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 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
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
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, February 22, 2009 4:18 PM Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
vicente.botet wrote:
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.
It found making the difference necessary after the comment From: "David Abrahams"
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.
If this is automatic we need a manual state for the verified fix. Vicente
vicente.botet wrote:
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, February 22, 2009 4:18 PM Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
vicente.botet wrote:
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.
It found making the difference necessary after the comment From: "David Abrahams"
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.
If this is automatic we need a manual state for the verified fix.
Nobody forces you to add "Fixes #xxx" text in commit message if you're not sure the commit fixes anything. You can always add this string at a later time, if so desired. - Volodya
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, February 22, 2009 5:44 PM Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
vicente.botet wrote:
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, February 22, 2009 4:18 PM Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
vicente.botet wrote:
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.
It found making the difference necessary after the comment From: "David Abrahams"
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.
If this is automatic we need a manual state for the verified fix.
Nobody forces you to add "Fixes #xxx" text in commit message if you're not sure the commit fixes anything. You can always add this string at a later time, if so desired.
Do you agree to have two status for fixed on trunk and fixed on release? Vicente
vicente.botet wrote:
If this is automatic we need a manual state for the verified fix.
Nobody forces you to add "Fixes #xxx" text in commit message if you're not sure the commit fixes anything. You can always add this string at a later time, if so desired.
Do you agree to have two status for fixed on trunk and fixed on release?
I think I've already commented on that: > FWIW, we have good experience with "fixed, not delivered" and "fixed, delivered" states. "We" here means "folks at my company". - Volodya
----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Sunday, February 22, 2009 6:12 PM Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
vicente.botet wrote:
If this is automatic we need a manual state for the verified fix.
Nobody forces you to add "Fixes #xxx" text in commit message if you're not sure the commit fixes anything. You can always add this string at a later time, if so desired.
Do you agree to have two status for fixed on trunk and fixed on release?
I think I've already commented on that:
> FWIW, we have good experience with "fixed, not delivered" and "fixed, delivered" states.
"We" here means "folks at my company".
Now you have, Vicente
Hi Dave ! On Sunday 22 February 2009, David Abrahams wrote:
on Sat Feb 21 2009, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
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.
Well, trac/subversion was not designed to handles such a setup. So no wonder it is breaking... Use something changeset based for this. git (or maybe bzr).
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.
I am monitoring the whole "release branch" hell for some time now. And most commits are "whole subtree" merges with messages like "Merge <mylib> to release". As long as no merge tracking is used (either svnmerge.py or Subversion server- and client-side > 1.5.5) this will simply not work.
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.
Well, those are getting slowly bigger... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
on Sun Feb 22 2009, Juergen Hunold <juergen.hunold-AT-ivembh.de> wrote:
Hi Dave !
Hi!
On Sunday 22 February 2009, David Abrahams wrote:
on Sat Feb 21 2009, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
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.
Well, trac/subversion was not designed to handles such a setup. So no wonder it is breaking... Use something changeset based for this. git (or maybe bzr).
SVN 1.5 can handle it, though I tend to agree that Git provides a much more appropriate model for Boost. It looks a bit to me like bzr is going to lose the popularity battle to Git.
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.
I am monitoring the whole "release branch" hell for some time now. And most commits are "whole subtree" merges with messages like "Merge <mylib> to release". As long as no merge tracking is used (either svnmerge.py or Subversion server- and client-side > 1.5.5) this will simply not work.
Yup. "whole subtree" merges are evil.
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.
Well, those are getting slowly bigger...
Quite. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (5)
-
David Abrahams -
Juergen Hunold -
Steve M. Robbins -
vicente.botet -
Vladimir Prus