Called "experimental". Into this would go proposed new Phobos modules, such that they will go out with dmd releases. Once they've been in use for a while and prove themselves, then they can be moved into std (or dropped).

This was proposed in the n.g. and seems to be well received.

Yah. Would that be std.experimental or just experimental? I suggest the former.

Andrei

On 3/28/11 7:05 PM, Walter Bright wrote:
> Called "experimental". Into this would go proposed new Phobos modules, such that they will go out with dmd releases. Once they've been in use for a while and prove themselves, then they can be moved into std (or dropped).
>
> This was proposed in the n.g. and seems to be well received.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I was thinking the latter...

On 3/28/2011 5:10 PM, Andrei Alexandrescu wrote:
> Yah. Would that be std.experimental or just experimental? I suggest the former.
>
> Andrei
>
> On 3/28/11 7:05 PM, Walter Bright wrote:
>> Called "experimental". Into this would go proposed new Phobos modules, such that they will go out with dmd releases. Once they've been in use for a while and prove themselves, then they can be moved into std (or dropped).
>>
>> This was proposed in the n.g. and seems to be well received.

Problem is that we'd occupy two top-level namespaces instead of one. Right now people know better than define a package called "std". From here onwards they'd need to remember that both "std" and "experimental" are verboten.

I wouldn't want to take the discussion much further, as I'm sure there are many nuances of paint for this bikeshed. If you want top-level experimental, go for it.


Andrei

On 3/28/11 7:22 PM, Walter Bright wrote:
> I was thinking the latter...
>
> On 3/28/2011 5:10 PM, Andrei Alexandrescu wrote:
>> Yah. Would that be std.experimental or just experimental? I suggest the former.
>>
>> Andrei
>>
>> On 3/28/11 7:05 PM, Walter Bright wrote:
>>> Called "experimental". Into this would go proposed new Phobos modules, such that they will go out with dmd releases. Once they've been in use for a while and prove themselves, then they can be moved into std (or dropped).
>>>
>>> This was proposed in the n.g. and seems to be well received.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Observation: We still have the 'etc' namespace with practically nothing in it.

On 29 March 2011 02:25, Andrei Alexandrescu <andrei at erdani.com> wrote:
> Problem is that we'd occupy two top-level namespaces instead of one. Right now people know better than define a package called "std". From here onwards they'd need to remember that both "std" and "experimental" are verboten.
>
> I wouldn't want to take the discussion much further, as I'm sure there are many nuances of paint for this bikeshed. If you want top-level experimental, go for it.
>
>
> Andrei
>
> On 3/28/11 7:22 PM, Walter Bright wrote:
>>
>> I was thinking the latter...
>>
>> On 3/28/2011 5:10 PM, Andrei Alexandrescu wrote:
>>>
>>> Yah. Would that be std.experimental or just experimental? I suggest the former.
>>>
>>> Andrei
>>>
>>> On 3/28/11 7:05 PM, Walter Bright wrote:
>>>>
>>>> Called "experimental". Into this would go proposed new Phobos modules, such that they will go out with dmd releases. Once they've been in use for a while and prove themselves, then they can be moved into std (or dropped).
>>>>
>>>> This was proposed in the n.g. and seems to be well received.
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

I'm basically in favor of this (I proposed a version of it) but how would it interact with the review process?  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.  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.

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.

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.

On 3/28/2011 8:05 PM, Walter Bright wrote:
> Called "experimental". Into this would go proposed new Phobos modules, such that they will go out with dmd releases. Once they've been in use for a while and prove themselves, then they can be moved into std (or dropped).
>
> This was proposed in the n.g. and seems to be well received.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

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

On 3/28/2011 5:30 PM, Don Clugston wrote:
> Observation: We still have the 'etc' namespace with practically nothing in it.

I know. But I think etc is a fine place for things like thin interfaces to C libraries, which it is currently used for. etc.c.zlib is not an experimental module.

On Tue, Mar 29, 2011 at 5:59 AM, Walter Bright <walter at digitalmars.com> wrote:
>
>
> On 3/28/2011 5:30 PM, Don Clugston wrote:
>>
>> Observation: We still have the 'etc' namespace with practically nothing in it.
>
> I know. But I think etc is a fine place for things like thin interfaces to C
> libraries, which it is currently used for. etc.c.zlib is not an experimental
> module.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

I was about to suggest something similar, wrote a message but never sent it because I thought it wouldn't take off. Now that we talk about it, here is a copy of it below:

We've been talking about newly submitted code review process recently. I think this a very important step for high quality code inclusion into Phobos. However, I think that we missed that not only we need to review all the new code being submitted, but also an existing code, some of which is old, buggy and unmaintained for years now.

I think everyone agrees that some of it needs to be deprecated. However, I don't think any of is going away anytime soon.

There is also a few existing modules improvement ideas circulating
around (streams, base64, join etc), but some of the changes may break
an existing code. Andrei tries to fit new design into old syntax,
which is both good (for backwards compatibility) and bad (it's very
limitating).

Also, it might be desired to introduce new features, gather feedback and (possibly) change some of the public API. This is not a very good idea for a library that claims to be stable, because of the breaking changes it might introduce in subsequent releases.

This is why I propose introducing new package into Phobos. I'd call it just "d". Within that package we could try new different ideas that we couldn't with std (because, once again, that would break existing code/TDPL examples).

The main idea behind this is to keep old code working for new Phobos revisions, while allowing introducing new features without caring much about backwards compatibility. In a long run, users would only use "d", and not "std" (unless they need some old stuff) thus effectively deprecating it.

I know many of you won't like it, but I thought I'd try. What do you think? Do we need to review all the existing Phobos code, or just take it as granted that it's "okay"? Is it a good idea to introduce new package top-level "d" and re-design Phobos from the ground up based on new API?

On Mon, 2011-03-28 at 17:05 -0700, Walter Bright wrote:
> Called "experimental". Into this would go proposed new Phobos modules, such that they will go out with dmd releases. Once they've been in use for a while and prove themselves, then they can be moved into std (or dropped).
> 
> This was proposed in the n.g. and seems to be well received.


I think it's a very good idea.  I'd prefer if we use etc or std.experimental for this, and not a new top-level package.

-Lars