Re: [boost] is review system in place is extremely slow? (wasRe:[rfc] rcpp)

Subject: Re: [boost] is review system in place is extremely slow? (wasRe:[rfc] rcpp)
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-25 00:56:53

Hi,
----- Original Message ----- 
From: "Robert Ramey" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, February 24, 2010 6:04 PM
Subject: Re: [boost] is review system in place is extremely slow? (wasRe:[rfc] rcpp)

> 
> Vladimir Prus wrote:
> 
>>> I'm the review manager of Boost.Task but the library is not ready
>>> for review, because now Boost.Task depends on Boost.Move,
>>> Boost.Fiber and Boost.Atomic (which is not yet on the review queue).
>>> Maybe the review withards could add this on the schedule page.
>>
>> It's perfectly OK to move those 3 libraries to the 'detail' namespace
>> of Boost.Task and have review as it is, as opposed to waiting. What
>> do you think?
> 
> I think I caught hell for doing something similar in the serialization
> library.  I had to make a number of components such as
> BOOST_STRONGTYPEDEF, state_saver, smart_cast, etc.
> which I put into boost  - (not detail) and year afterwards this
> was raised as a huge problem.  And this was even though the
> components had been their through two reviews.  So I would
> be careful about doing this.
> 
> Another issue is: if Boost.Task depends upon Boost.Fiber
> and Boost.Atomic, what happens if the Boost.Fiber or
> Boost .Atomic are not approved?

Boost.Fiber and Boost.Atomic are used internally so not matter for these dependencies. Oliver had its own atomic implementation, and he has changed recently to use Boost.Atomic. He could include Boost.Atomic in a detail namespace if necesary. In addition Oliver is the author of Boost.Fiber.

The single problem is for libraries used at the user level interface, and for Boost.Task tis is the case for Boost.Move.
So the single imperative dependency to solve is Boost.Move.

Best,
Vicente