Re: [boost] Boost.Build merge?

Subject: Re: [boost] Boost.Build merge?
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-10-11 14:26:41

Eric Niebler wrote:

>> This would
>> eliminate the requirement for any kind of "freeze"
>
> Let me understand ... it would eliminate the need for a tool freeze
> *on trunk*, not on release. A freeze on the release branch is
> essential and standard practice. And IMO the freeze on tools should
> happen earlier ... by some weeks as Volodya suggested ... than the
> freeze on libraries.

OK - I guess we're sort of splitting hairs here.  as a practical
matter, I would be reluctant to merge any changes into the release
near to the release target date.  It would be on a case by case
basis.

Actually, its interesting I find myself in exactly this situation
right this minute.

We have a bug in the serialization library.  It only shows up in
certain circumstances on certain versions of the gcc compiler
and on none of the test platforms.  (I don't think anyone will
argue that the serialization library doesn't have enough tests).
It's ever worse, if one has this bug, there is no way to work
around it. Now, after months of trying to track this down,
Troy d. straszheim has managed to make a repeatable test that fails in
his environment and I think I've finally managed to fix it.
It looks like the latest fix hasn't broken anything else and
hopefully Troy will be able to verify that his test case now
passes.  This illustrates the following for the new procedure.

a) In spite of one's best efforts, s*** happens.
b) This situation isn't holding up the whole release for
everyone else
c) Even if we don't get the bug fix into this release,
the serialization and boost 1.37 as a whole will be strictly
better than the previous  version.
d) These improvements will be be available to users in a
timely manner.

So, I believe our experience with the current release
process demontrates a huge improvement over the previous
one.

Robert Ramey