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 !