Re: [boost] Why the integration branchmust remain clean, etc.

Subject: Re: [boost] Why the integration branchmust remain clean, etc.
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-06-12 14:20:47

David Abrahams wrote:
> on Mon Jun 08 2009, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>
>> David Abrahams wrote:
>>
>>> I suppose another approach might be to test against the release
>>> branch, then svn switch to the trunk and check in my changes there.
>>
>> This has worked very well form me.
>>
>>> But that is still laborious.
>>
>> And it's not laborious at all.
>
> It is.  You're suggesting something else:
>
>> I have a boost release tree on my machine.
>> The three directories relateded to the serialization library have
>> been switched to the trunk.
>
> I was talking about switching the whole tree over to trunk just before
> checkin (and testing again to make sure you're not breaking anything
> there).

This amounts to using the "rest of boost" to test one library.  For
most libraries this isn't very cost/time effective.  It really tests for
interface breaking change.  I wonder, do you go back and check
ALL the failures in All the libraries to see which one's might
be related to the changes in your library and which ones are not?
That would be a huge amount of work.  Perhaps it might be worth it
for MPL, but for most libraries I doubt it.

> Your approach works pretty well until you find an issue in some
> utility outside your own library --- say, it needs a workaround for a
> compiler you're testing against --- and you have to make a tweak
> there.  You risk checking that tweak in on the release branch.  Also,
> I'm responsible for more diverse areas of the Boost SVN tree than you
> are, so it might get hard to keep track of which parts are switched.

I totally understand this.  One thing that might be considered is that
the release branch be locked by the release manager and unlocked
as each developer want's to merge.  This would give the release
manager a means to excercise authority he might require. At this
time, I'm not willing to argue for this though, I'm aware of the
tradeoffs.  Actually, I would just leave this option to the discretion
of the release manager.  I could easily imagine that he might want
use this idea just when release is close.

> Also there's a good chance of breaking something in the trunk because
> you haven't tested against that code.  Hmm, a clean compile against
> the trunk is supposed to be a prerequisite for a merge to release,
> but not testing against the trunk might be a gamble worth taking if
> that breakage is rare enough.

FWIW, I test locally my one library against a couple of compilers
that I have then check into the trunk and see what happens. (that
is, wait for complaints).  Since not very much is dependent on
the serialization library, this hasn't happened in years?

> Seems like this approach could
> contribute a little to making the trunk more broken overall, though,

> and we both agree that brokenness on trunk is a problem.

Ahhhh - this is the crux of matter for me. I don't agree with this.
The trunk is never released.  The trunk is aways broken and its
only a problem because people test against it.  If the trunk
system testing were changed so that each library were tested
against the current release this wouldn't be noticed at all.

Basically, changing more than one variable (library) at a time
and then testing hides information.

Some time ago, I changed the serialization library tests so
as not to use the boost test component.  It's not that boost
test was bad, it's that the testing the serialization library
with a test system which was still in flux generated a huge
amount of work in tracking down source of test failures.
Same goes for boost build.  Now I test locally only against
release and I don't have those problems.  Now that I"m doing
that, I might well go back to using boost test.

>> Take my advice.
>
> I'll try it, but I'm worried that it's more viable for you than it is
> for me for some of the reasons I cited above.

Hmm - I should have said, "Try my method"

Robert Ramey