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

Subject: Re: [boost] Trac tickets: fixed in trunk vs. fixed in release
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-22 12:31:46

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