Subject: Re: [boost] is review system in place is extremely slow? (wasRe:[rfc] rcpp)
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-02-24 18:25:06
Pete Bartlett wrote:
> 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.
It looks like the author of Atomic has not even asked for a review, since it is not in the schedule. I can't even find Atomic in the vault or sandbox.
I looked at Fiber in the vault and sandbox and it has no documentation. If a library has no documentation it is not a library, its just code. I looked at Move in the sandbox and it also has no documentation. If documented properly Move probably could be fast tracked because there is so little code there.
Rather than direct frustration at boost for the slowness of the review process, how about directing your frustration at the library authors who aren't bothering to write documentation and get into the review queue? Who would agree to be review manager for a library with no documentation? I think acceptance into boost sounds like a great idea to a lot of talented programmers until they find out they have to spent significant effort writing high quality documentation. For the ones who follow through the review process works just fine. Once the libraries are in a state where they could be accepted and the authors are active in requesting a review and looking for a review manager and it still isn't happening then you can complain that the process itself is broken.
If you want these libraries accepted why don't you go ahead and take over responsibility for them, get the documentation up to acceptable standards and ask for reviews yourself?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk