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