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: Pete Bartlett (pete_at_[hidden])
Date: 2010-02-24 17:58:40

>From  Robert Ramey
> > 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.

This seems a little more negative than I remember. If we are thinking of the
same thread (see e.g.
http://lists.boost.org/Archives/boost/2007/11/130567.php ) then a lot of the
discussion was about headers directly in the boost root directory rather
than a subdirectory, rather the issue at hand.

My opinion is that there is no overarching programming design deity that is
going to come down and smite us if we be a bit pragmatic. So what if Move
[*], Fiber and Atomic get "smuggled" in if Task gets reviewed and accepted
first? They don't have to be documented as accepted - on the contrary the
documentation could have appropriate warnings as *not* formally accepted
apart for indirect use via Task.

>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?

Sometimes the laudable goal of perfection turns open source projects into
games of Nomic! Again, pragmatism should play a role here else Boost will
never be the rich and full set of libraries that it fantastically could be.

Pete

[*] Move seems so core these days - another bit of pragmatism would see that
fast-tracked through.