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

Subject: Re: [boost] is review system in place is extremely slow? (was Re:[rfc] rcpp)
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-24 11:26:30

----- Original Message ----- 
From: "Vladimir Prus" <vladimir_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, February 24, 2010 12:15 PM
Subject: Re: [boost] is review system in place is extremely slow? (was Re:[rfc] rcpp)

> 
> vicente.botet wrote:
> 
>> Hi,
>> ----- Original Message -----
>> From: "Mathias Gaunard" <mathias.gaunard_at_[hidden]>
>> To: <boost_at_[hidden]>
>> Sent: Tuesday, February 23, 2010 12:47 PM
>> Subject: Re: [boost] [rfc] rcpp
>> 
>> 
>>> 
>>> Ivan Sorokin wrote:
>>  
>>>> 3 When will Boost.Move become a part of boost?
>>> 
>>> When it gets reviewed.
>>> It could be said, however, that the review system in place is extremely
>>> slow and that it's going to take years (literally).
>> 
>> 
>> Why do you think the review system in place is extremely slow?
>> 
>> Currently there are a lot of libraries to review, but no review managers. That means that the user
>> community don't want to spend a little bit of their time to manage a review.
>> 
>> In addition, the last review didn't had too much of reviewers (I'm also concerned by this point)
>>  
>> 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?

Hi,

This is what I proposed to Oliver. Boost.Fiber and Boost.Atomic are internal details, but Boost.Move is seen by the user. So we will need just to wait for Boost.Move. Oliver let me know what do you think.

I could manage with the review of Boost.Move if the review withards and the author agree, but I think this library should be managed by someone having a very good knowledge of the emulated C++ Move semantics. Is there a candidate?

Best,
Vicente