Subject: Re: [boost] trunk vs release
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-05-22 01:16:57
John Phillips wrote:
> Robert Ramey wrote:
>> Here's the scenario.
>> a) I make a breaking change to serialization.
>> b) after testing in the trunk - I merge into the release queue
>> c) MPI tests start to break.
>> d) I get an email from the MPI authors which starts Dear
>> $#$#%$%$&$^*%^* e) Haggling involving me, the MPI authors and
>> perhaps the release manager result in one of the following:
>> i) backing out changes in the serializaiton library
>> ii) MPI authors accomodating the change.
>> Robert Ramey
> I suggest a slight variation on this.
> a) Make breaking changes to Serialization
> b) Testing the changed Serialization against the release branch shows
> that it would break MPI, so it is not merged to release, yet
It didn't occur to me that this would happen. But of would under the
current testing regimen where all dependencies are re-tested.
> c) Polite conversation with MPI authors tries to convince them that
> the new version serves their needs even better than before (or whatever
> else it takes to get them to modify)
> d) MPI authors modify, and testing system allows you to test the
> combination of new Serialization and new MPI against release branch
> e) Tests are all green, so new versions roll in together
> I understand that building a test system that could accomidate this
> is not going to be easy,
I totally disagree with this - the current bjam/test software could be
used without change. Only a (small?) change to the python test script
would be necessary.
>but it would minimize the need for focused
> testing of the release branch, and within oddities should keep release
> in a clean state. It also reduces the chance for - you broke my tests
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk