Subject: Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2010-02-23 12:00:30
> Why do you think the review system in place is extremely slow?
Because some libraries that are in the review queue won't make it to
boost before several years, even if they're polished and ready for
usage, and that's quite a shame.
I would even say that's a problem that is putting boost at risk as it
cannot scale to more projects than it already has, which means it may be
losing on the innovation side.
I may however be exaggerating, but it doesn't seem like that many people
share those sentiments within Boost and feel concerned about this issue.
> 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)
So you can see, indeed, that this is fairly concerning.
I think this is mostly the case for specialized libraries, though. The
more precise the domain, the more little people know about it; and you
wouldn't want people that know very little about something to review it.
Maybe separating a "core" boost containing only small-ish
general-purpose utilities from other libraries might help.
> What do you propose to improve it?
I don't claim to have a solution, but I've got what I think may be an
idea worth investigating.
What I suggest is creating an unstable branch where all libraries that
satisfy simple quality criteria can be added, with the same layout as
the trunk, with some automatic tests being run, a bug tracker etc.
That way they get exposure, usage, and thus become easier to review
later on. Authors also feel more involved, and work is not done in
isolation as the branch contains the whole of boost.
A library may then get elected to the stable branch, which means you
simply have to merge it to the trunk.
It could be said it is just a glorified sandbox, but I believe the
changes from the sandbox are enough to make it significantly different.
What the "simple quality criteria" are remains to be defined, but it
should be something that only requires review from one single person
within the pool of approved reviewers and that isn't too time-consuming.
You would also probably need a community coordinator to make sure the
unstable branch doesn't become too much of a mess.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk