Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)

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

vicente.botet wrote:

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