Hi,

I think we need a semi-formal process for experimental Phobos modules. That is, modules that are slated for the Phobos review process and/or eventual inclusion in Phobos but needs actual field testing to work out a proper interface or implementation.

(I'm assuming most people in the community think an experimental package namespace in Phobos is a good idea.)

Some people see the "etc" package as being this but I think it's too poorly named. Something like "experimental" (or just "exp") would be more sensible IMO.

Does anyone have any thoughts on how we might do this? Any bikeshedding? I'm not really sure what the best way to go about this is, so really, any input is very welcome.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Wednesday, December 05, 2012 09:27:39 Alex Rønne Petersen wrote:
> Hi,
> 
> I think we need a semi-formal process for experimental Phobos modules. That is, modules that are slated for the Phobos review process and/or eventual inclusion in Phobos but needs actual field testing to work out a proper interface or implementation.
> 
> (I'm assuming most people in the community think an experimental package namespace in Phobos is a good idea.)
> 
> Some people see the "etc" package as being this but I think it's too poorly named. Something like "experimental" (or just "exp") would be more sensible IMO.
> 
> Does anyone have any thoughts on how we might do this? Any bikeshedding? I'm not really sure what the best way to go about this is, so really, any input is very welcome.

Given the discussions of stability of late, I _have_ wondered if we would be better off if instead of directly merging new modules into Phobos, we put them in a package (e.g. experimental) which was known to be temporary so that people could mess around with it before its API was more or less set in stone. Only after some time in there would they actually move into Phobos proper. The review process helps a great deal, but the modules don't always get much use before they're actually merged in, and actual use can definitely reveal flaws that even a solid review won't.

Whether we want some kind of experimental set of modules in Phobos which _could_ be reviewed, I don't know. I'm inclined to think that that's a bad idea. However, it might be a good idea if we had a separate project (akin to Boost perhaps) with a lower standard for inclusion and minimal long term stability so that more modules could be tested and tried out before going through the actual review process. It would also potentially make it easier for programmers to take other people's code and make it Phobos ready when the original programmers are willing to write it in the first place but not got the extra mile to make it Phobos ready, as they could put into that incubator project to be used, abused, and improved by others.

Regardless, I think that we need to look at finding ways to make sure that major inclusions to Phobos get more actual field testing before being put into Phobos in their final form. The review process is great, but I don't think that it's always enough to make sure that a module's API is really going to work long term. And if we want long term stability, we need to make sure that new modules are really ready to have their APIs essentially frozen when they make it into Phobos proper (allowing further additions but avoiding breaking compatibility with any changes that are made).

- Jonathan M Davis

On Wednesday, 5 December 2012 at 08:27:39 UTC, Alex Rønne Petersen wrote:
> Hi,
>
> I think we need a semi-formal process for experimental Phobos modules. That is, modules that are slated for the Phobos review process and/or eventual inclusion in Phobos but needs actual field testing to work out a proper interface or implementation.
>
> (I'm assuming most people in the community think an experimental package namespace in Phobos is a good idea.)
>
> Some people see the "etc" package as being this but I think it's too poorly named. Something like "experimental" (or just "exp") would be more sensible IMO.
>
> Does anyone have any thoughts on how we might do this? Any bikeshedding? I'm not really sure what the best way to go about this is, so really, any input is very welcome.

Years ago I've suggested to introduce an incubator project.

On Wednesday, 5 December 2012 at 08:27:39 UTC, Alex Rønne Petersen wrote:
> Hi,
>
> I think we need a semi-formal process for experimental Phobos modules. That is, modules that are slated for the Phobos review process and/or eventual inclusion in Phobos but needs actual field testing to work out a proper interface or implementation.
>
> (I'm assuming most people in the community think an experimental package namespace in Phobos is a good idea.)
>
> Some people see the "etc" package as being this but I think it's too poorly named. Something like "experimental" (or just "exp") would be more sensible IMO.
>
> Does anyone have any thoughts on how we might do this? Any bikeshedding? I'm not really sure what the best way to go about this is, so really, any input is very welcome.

Years ago I have suggested to establish an incubator project.

On Wednesday, December 05, 2012 15:10:59 Pragma Tix wrote:
> Years ago I have suggested to establish an incubator project.

It's been suggested a few times, but no one ever does it. As with a lot of things around here, unless someone steps up and champions it, it isn't going to happen.

- Jonathan M Davis

In the Linux community it is called 'staging', rather than 'experimental'.
A module has to be of some quality level to be accepted to staging, where it may be reviewed and tested by the more adventurous people.
From staging, the module proceeds to the mainline, or back to hell.
In Linux this approach pretty much proves itself.

On Wednesday, 5 December 2012 at 08:43:39 UTC, Jonathan M Davis wrote:
> Whether we want some kind of experimental set of modules in Phobos which
> _could_ be reviewed, I don't know. I'm inclined to think that that's a bad
> idea. However, it might be a good idea if we had a separate project (akin to
> Boost perhaps) with a lower standard for inclusion and minimal long term
> stability so that more modules could be tested and tried out before going
> through the actual review process. It would also potentially make it easier
> for programmers to take other people's code and make it Phobos ready when the
> original programmers are willing to write it in the first place but not got the
> extra mile to make it Phobos ready, as they could put into that incubator
> project to be used, abused, and improved by others.
>
> Regardless, I think that we need to look at finding ways to make sure that
> major inclusions to Phobos get more actual field testing before being put into
> Phobos in their final form. The review process is great, but I don't think that
> it's always enough to make sure that a module's API is really going to work
> long term. And if we want long term stability, we need to make sure that new
> modules are really ready to have their APIs essentially frozen when they make
> it into Phobos proper (allowing further additions but avoiding breaking
> compatibility with any changes that are made).
>

I think D isn't big enough to get that into another project. Many people wont use that just because you need a setup when they would if they don't need to, while knowing they use something that isn't casted in stone.

experimental seems the right name to me :
- It is long.
- It is explicit.

On Wed, Dec 05, 2012 at 06:47:38PM +0100, angel wrote:
> In the Linux community it is called 'staging', rather than
> 'experimental'.
> A module has to be of some quality level to be accepted to staging,
> where it may be reviewed and tested by the more adventurous people.
> From staging, the module proceeds to the mainline, or back to hell.
> In Linux this approach pretty much proves itself.

I like the name 'staging'. Spelling it out in full is also good, so that people who use it only do so deliberately. Like staging.io for the prospective new std.io, or staging.graph for a hypothetical graph algorithms module destined for std.graph, it's immediately clear that these are experimental/staging modules, not yet official.

It can even be provided as part of Phobos (or rather, part of the Phobos package, under the staging namespace) so that it's convenient for people to test things out. To maximize test coverage by actual-use code, I don't think it's a good idea to make people jump yet another hurdle to install a staging package. Bundle it with Phobos and let everyone have ready access to it, with the understanding that APIs from staging will not be stable, and things may change drastically without warning. Requiring people to download, install, and configure yet another package only raises the barrier, and we'd probably get few or no testers at all, which defeats the purpose of staging.


T

-- 
Ruby is essentially Perl minus Wall.

On 05-12-2012 17:10, Jonathan M Davis wrote:
> On Wednesday, December 05, 2012 15:10:59 Pragma Tix wrote:
>> Years ago I have suggested to establish an incubator project.
>
> It's been suggested a few times, but no one ever does it. As with a lot of
> things around here, unless someone steps up and champions it, it isn't going
> to happen.
>
> - Jonathan M Davis
>

In this case, though, there isn't really much to *do*. People just need to send pull requests when they have a module they feel is ready for field testing.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Wednesday, December 05, 2012 21:32:37 Alex Rønne Petersen wrote:
> On 05-12-2012 17:10, Jonathan M Davis wrote:
> > On Wednesday, December 05, 2012 15:10:59 Pragma Tix wrote:
> >> Years ago I have suggested to establish an incubator project.
> > 
> > It's been suggested a few times, but no one ever does it. As with a lot of things around here, unless someone steps up and champions it, it isn't going to happen.
> > 
> > - Jonathan M Davis
> 
> In this case, though, there isn't really much to *do*. People just need to send pull requests when they have a module they feel is ready for field testing.

Yes. But I think that that's completely inappropriate for putting into Phobos. We would actually need a separate project for that. And someone would need to set up and manage that project. Given that they wouldn't be doing code reviews or maintaining the code or whatnot, it's not at all the same as getting someone to take the time to produce a large piece of functionality for Phobos and might ultimately end up not taking much time from the person leading the project. But someone still needs to step up and do it. And no one has done that. Several have suggested it, and a number of us have agreed that it's a good idea, but as long as no one actually takes the initiative and actually does it, it's just a nice idea.

- Jonathan M Davis