Re: [Boost-users] run_test parameter not working (Boost Unit Test Framework )

From: Daryle Walker (darylew_at_[hidden])
Date: 2008-07-28 08:15:09

On Jul 24, 2008, at 4:28 PM, Gennadiy Rozental wrote:

> Juergen Hunold <juergen.hunold <at> ivembh.de> writes:
>
>> On Wednesday 23 July 2008 19:34:31 Gennadiy Rozental wrote:
>>> This hopefully is going to be part of next release (not sure if I  
>>> need to
>>> do anything for this to happened).
>>
>> Well, unfortunately not ( You had to to merge the libs to the release
>> branch according to http://svn.boost.org/trac/boost/wiki/ 
>> ReleaseSchedule
>> and http://svn.boost.org/trac/boost/wiki/ImprovingPractices
>
> Not sure how it's an improvement. What is being used as base for  
> release brunch?
> Why not pick up library trunk state automatically if it's passing  
> all tests?

AFAIK, the trunk _is_ what is used to base the release branch, from  
some cut-off point the release manager decides, and informs the group  
about.  Each library's maintainer should merge the readiest, but non- 
revolutionary, revision of his/her library around that cut-off point  
back into the release branch (if the cut-off point's revision is  
insufficient).  If you been making either evolutionary changes or a  
non-bleeding-edge revolutionary change, you should merge in the last  
revision of those changes after the cut-off.  If you just made a  
bleeding-edge change (i.e. you don't know all the consequences to all  
the platforms and/or fixed most of them), you should merge in the  
revision before the cut-off that is before the change.

Just grabbing off the trunk is irresponsible.  Even if we keep the  
trunk release-ready, which we are striving for, trunk-grabbing  
requires that we PROVE the release-readiness.  That requires that we  
build & unit-test on every check-in (and reject failures).  AFAIK, a  
Boost source tree requires hours to test, even if we run each  
platform vs. compiler/linker vs. configuration-parameters combination  
in parallel.  This would back up our check-in times considerably,  
which is impractical.  That's why we need a separate scratch space  
for our release trees, for proper clean-up and testing.

>> Well, I think you have to ask to release manager for permission to  
>> merge this
>> one.
>
> Not sure I'll have time for this double work. Anything that in a  
> trunk can be
> (and should be) released.

And that would be problematic for anyone who deliberately skipped the  
cut-off to add bleeding-edge changes (like me and Boost.Integer).  We  
would have to warn the release manager to back out stuff, including  
any dependencies on the new stuff.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com