[phobos] proposal for new top level package name "experimental"

[spir]

On 03/29/2011 02:46 AM, David Simcha wrote:
> I'm basically in favor of this (I proposed a version of it) but how would it
> interact with the review process?

I think some of the numerous unfinished or abandoned D packages or modules 
(including ones for D1), but having good potential in quality and community 
interest, could be brought back there. As an invitation to restart effort of 
the features we need.

> My suggestion is that an abbreviated review
> (maybe 1 week review, 2 day vote) is required to make sure a module isn't
> complete junk, duplication of functionality already in Phobos, etc. and get it
> in experimental.  Voting "yes" here means the voter believes the module has
> enough merit to be worth the author's effort to improve and the community's
> effort to review more thoroughly.  It does not necessarily mean the module is
> up to Phobos standards as-is.  This also provides a procedure for filtering out
> modules with little potential, with minimal work on everyone's part.

That's a good point, too.

> The
> purpose of experimental is to conduct a more thorough review over the course of
> one or a few release cycles before accepting the module into std.  While a
> module is in experimental, breaking changes may be introduced at the drop of a
> hat.  This is the place for the module to be thoroughly refined.

Yes, that's a place where we should not hesitate to "revolution" design & 
implementation for the sake of long-term quality.

> At the end of every release cycle, we should have a vote.  For each module, a
> community member may vote:
>
> 1.  Accept into std.
> 2.  Keep in experimental.
> 3.  Reject, remove from experimental.

Also, a package/module may simply be found not to have its place in Phobos 
because of, say, not general enough. I'm thinling at things like a CSV parsing 
lib possibly later replaced by a slightly more general module. (I don't mean it 
should be the case for CSV, it's just an example.)

> If a majority (not plurality) vote reject, the module is rejected.  If a
> majority (not plurality) vote accept, it's moved into std.  If a plurality (not
> necessarily majority) vote to keep it in experimental, it stays in experimental.
>
> Overall, having the modules in review be bundled with DMD, ready to be used
> will lower the barrier to entry for people who are curious about them.  It's
> also a good way to organize the modules in review at any given time.

That's the strong point of the proposal. People who need those services will 
certainly try the proposals more easily.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com