Re: [boost] [1.33.0] Final release schedule

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-29 19:51:44

"Robert Ramey" <ramey_at_[hidden]> writes:

> David Abrahams wrote:
>> "Robert Ramey" <ramey_at_[hidden]> writes:
>>
>>> These particular ones are due to the fact that I've never been able
>>> to force the order of tests with bjam.  Those tests attempt to load
>>> archives which haven't been created yet.  If one doesn'st clean out
>>> the $TMPDIR, these errors don't occur the next time.
>>
>> I can't believe I'm only hearing about this now.  Did I miss your
>> request for help with this problem on the jamboost list?
>
> Oh yeah - there were quite a few emails regarding trying to get bjam to do 
> what I needed it to do.  Fixing the order of the save/load tests was just 
> one issue.  

<snip>

> Rene did submit a Jamfile patch to address the final problem.  It
> was totally opaque to me in that it depended upon internal behavior
> of bjam.

So? What can you put in a Jamfile that *doesn't* depend on the
internal behavior of bjam??  Are you saying you understand the details
of everything else bjam is doing?

> I really had spent a lot of time with bjam and was concerned that
> including this might interact with all the issues resolved above in
> a way that I could never figure out.  That is, I felt the cure was
> worse than the desease.  

Maybe for you, but having regressions is much worse for everyone else
than having a Jamfile that you don't understand.

> So I left out this last change for the sake of transparency.  I did
> leave in "Depends" clauses to document the requirement that the save
> test be run after the corresponding load test.  This doesn't work
> but it does document my intention.

What good is that to the rest of us?

Bogus failure reports are worse than no failure reports at all,
because everyone will ignore them *and* be annoyed by them.  Also it
will make users unnecessarily nervous.  At least with no failure
reports, you avoid the annoyance/nervousness factor.  

>>> Using the markup to indicate - fails sometimes resulted in a
>>> misleading marking of the passing tests (If I remember correctly) so
>>> I just had to leave it.  That is, the "fail" are really artifacts of
>>> the bjam implementation.
>>
>> Seems to me it's an artifact of the fact that you didn't figure out
>> how to make it do what you want.
>
> LOL

Now that I read your description of history, it seems to be just an
artifact of your unwillingness to use Rene's fix.

Rene spent quite some effort on figuring out how to let you specify
ordering and make it work.  I think you should make sure his efforts
don't go to waste.  If you need to be more comfortable with the code,
get him to explain it until you understand it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com