Managing the review queue

[Bruno Medeiros]

On 28/03/2011 20:19, Walter Bright wrote:
> On 3/28/2011 12:18 PM, dsimcha wrote:
>> == Quote from Walter Bright (newshound2 at digitalmars.com)'s article
>>> A further issue with the review process is that the bulk of people
>>> won't look at
>>> something until it is actually released. I think the only way to deal
>>> with this
>>> is to be willing to correct deficiencies found after release.
>>
>> Please clarify "release". If you mean making the code and
>> documentation public
>> and conveniently accessible, that's the point of the review process.
>> If you mean
>> actually including it with the DMD distribution, then maybe we need an
>> "incubator"
>> package as others have suggested. Things would get in incubator after
>> abbreviated
>> review. While in incubator we'd make no guarantees about their
>> stability or even
>> their continued inclusion. The "real" review would take place over a
>> release
>> cycle or two, while the module was in incubator. After each release
>> cycle, we'd
>> make a three-way decision. A module can:
>>
>> 1. Be declared stable and promoted to std.
>>
>> 2. Be declared not worthwhile and removed.
>>
>> 3. Kept in incubator pending further review and improvements.
>
> I have thought in the past about putting such modules into another
> package, call it "foo" for lack of a better name, and put it in the dmd
> distribution. If the package pans out in real life, then move it to std.
> So, yes, I think your idea is a good one.

Hum, this seems like an very interesting idea, it should definitely be 
considered (perhaps, especially so if the number of people participating 
in the review process remains low?).
So, a kind of incubator/experimental package. The modules here should be 
fairly stable (in terms of bugs), but the API would not be stable, it 
would change as people used the lib, feedback was received, changes were 
made, etc.

-- 
Bruno Medeiros - Software Engineer