From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-06-01 13:16:06
On Wed, 1 Jun 2005 13:29:27 -0400
"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote:
> Also, please note, that in case of typeof, a very active support of a
> very prominent boost member, didn't ensure large number of reviews.
> Meanwhile I am very much puzzled with the inconsistency of rather high
> download activity and relatively low amount of feedback the Typeof
> library has received on the list. If somebody could offer a
> reasonable explanation of this fact, it would help us a lot in our
> future work with boost.
As discussed in the past, I think the review period is way too short. I
would much rather we have multiple reviews going on at the same time,
with each one alloting about a month, rather than the 10 day period we
now have. I think it would garner much more feedback, and the quality
of the reviews would improve as well. Go back and look at the recent
library reviews (not just typeof), and you will see that very few people
have time to do really in-depth reviews.
Yes, I know everyone handling the reviews is a volunteer, but so are the
individuals attempting to do a review. I have barely participated in
any reviews, not because of interest, but because I can not manage to
download, read, test, review, code examples, write my questions,
consider the feedback, etc. in such a short timeframe. The one time I
tried to start working on a review well ahead of the scheduled start
time, the library changed significantly right before the review started.
Thus, for the most part, I end up reviewing stuff well after it has been
accepted (and, sadly, there are some libs that I just will not use,
though I may have used them if I would have offered input and gotten
changes during the review). Unfortunately, once a library is accepted,
getting changes to interfaces or design is near impossible, as evident
by several recent threads.
Please don't take me wrong... I love boost, and I use some of it.
However, I think the review process could be vastly improved by
significantly lengthening the review timeframe.
If that is not possible, then we should freeze a lib once it has been
submitted for review. It gets reviewed as submitted. This would
provide a built-in lengthening of the review, basically from the point
in time where the lib is placed on the queue, until the time the review
is finished. If the lib needs to be changed before the review, then it
should be removed from the queue, and placed at the back.
My $0.02, FWIW
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk