Experimental Phobos modules?

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Dec 5 14:15:23 PST 2012


On Wed, Dec 05, 2012 at 10:52:09PM +0100, Alex Rønne Petersen wrote:
> On 05-12-2012 22:05, Jonathan M Davis wrote:
> >On Wednesday, December 05, 2012 21:32:37 Alex Rønne Petersen wrote:
[...]
> >>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.
[...]
> Separate project? That kind of defeats the entire purpose: Making
> the to-be-tested module readily available to everyone...
[...]

Yeah, doing a separate project pretty much defeats the entire purpose.
It will have limited availability (not everyone will know where to look
for it) and limited incentive to be used (why install another package
manually, much less an *experimental* one?).

I say we should just create a staging/ directory in Phobos alongside
std/, and put the experimental/staging stuff there. With a big fat
notice that everything in staging/ is fair game for incompatible API
changes and breakages without any warning.

This will (1) encourage more users to test the new code, since it's
already sitting right there alongside the official part of Phobos, and
(2) when it comes time to accept it into std/, it's a trivial rename
rather than a possibly messy code merge from a foreign repo.


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.


More information about the Digitalmars-d mailing list