Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-09-08 11:35:33


On Wed, 8 Sep 2004 17:44:59 +0200, Thorsten Ottosen wrote
> "tom brinkman" <reportbase_at_[hidden]> wrote in message
> news:chm2sp$bs9$1_at_sea.gmane.org...
> | The current schedule allows ten days for each review.
> | It has been brought to my attention that this is too aggressive.
> | For the next couple of reviews, I will contact the library review managers
> | to arrange new start dates to allow for longer review periods and
> to also | ensure that they do not overlap. In my next status report,
> I will explain | this change in the schedule and try to contact the
> remaining library | authors for new start dates. | | My Concerns: |
> 1) The review process is slow.
>
> yeah, this is the problem.

Well, I don't see the 'slowness' as a problem. I think we have a problem
because we have a backlog of submissions. There were some significant periods
where reviews didn't keep up with the pace of submissions and now we have a
bunch of catch-up to do.

My only suggestion for shortening the formal review period would be to somehow
encourage or develop reviews of libraries in advance -- thus reducing the
amount of comment during the formal review. Anyone can go review boost::fsm,
just to pick one, and go review the code and docs and post it to the list.
The problem is, however, there is an additional dynamic during the formal
review -- reviewers read other reviews and discuss them. Perhaps if there was
a way of gathering review comments over a longer period (via wiki page or
something) we could shorten this last phase.

In a different dimension, the backlog is good thing -- I'm personally
heartened to see a raft of useful libraries being brought to boost. Boost has
been a must-have for c++ programmers for quite awhile now, but it's starting
to kick into high gear now.

> I could accept review overlaps if it became the review managers job
> to put together a group of people guaranteed to make a review. The
> size of this group would depend on the library's size.

I think this is very difficult to do practically...

Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk