Subject: Re: [boost] A Remedy for the Review Manager Starvation
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2010-05-15 16:03:10
On 15 May 2010 20:32, Daniel Walker <daniel.j.walker_at_[hidden]> wrote:
> On Sat, May 15, 2010 at 1:07 PM, Paul A. Bristow
>> The main improvement should come from more eyes viewing the code - isn't that the strength of Open Source?
>> To achieve this we need a way to get more 'candidate code' in real-life use by more people for a much longer period of
> Ditto. That's the heart of the issue, I think.
I'd also be interested in this. I picture three releases:
The goal here would be a quick way for people to grab what's out
there, find something they're interested in, and, if possible, use it.
I'd love to see this "released" automatically every week by a script.
Getting in should be as easy as the developer adding the name of
their sandbox subdirectory to a textfile in the sandbox root (which
would be automatically removed if the script had any problem grabbing
everything from that directory).
What we have right now. While it wouldn't need any changes, it might
help the schedule to say that a library can't go to formal review
until there are 3 "accept" preliminary reviews filed, which can be
done at any point while the library in question is in Candidate. This
would be released twice a year, say Q2 and Q4 (and people can always
use it from candidate if they can't wait the extra 4 months over the
A community vision of TR2. Essential parts that have passed some
extra bar. I see this as for portability necessities and things
needed to write other libraries, rather than implementations of
specific things, so it would probably get Thread and MPL, but likely
not GIL or CRC, for instance. I suspect less than half of the current
libraries should end up in here. This would get one release a year in
Q1, with a bugfix release in Q3 if needed.