www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Experimental Phobos modules?

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
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
Dec 05 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 05, 2012 09:27:39 Alex R=C3=B8nne Petersen wrote=
:

 Hi,
=20
 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 o=


ut

 a proper interface or implementation.
=20
 (I'm assuming most people in the community think an experimental pack=


age

 namespace in Phobos is a good idea.)
=20
 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.
=20
 Does anyone have any thoughts on how we might do this? Any bikesheddi=


ng?

 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 wou=
ld be=20
better off if instead of directly merging new modules into Phobos, we p=
ut them=20
in a package (e.g. experimental) which was known to be temporary so tha=
t=20
people could mess around with it before its API was more or less set in=
 stone.=20
Only after some time in there would they actually move into Phobos prop=
er. The=20
review process helps a great deal, but the modules don't always get muc=
h use=20
before they're actually merged in, and actual use can definitely reveal=
 flaws=20
that even a solid review won't.

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

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

- Jonathan M Davis
Dec 05 2012
next sibling parent reply "angel" <andrey.gelman gmail.com> writes:
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.
Dec 05 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Dec 05 2012
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Dec 05 2012
prev sibling next sibling parent "Pragma Tix" <bizprac orange.fr> writes:
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.
Dec 05 2012
prev sibling parent reply "Pragma Tix" <bizprac orange.fr> writes:
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.
Dec 05 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Dec 05 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
Dec 05 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Dec 05 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 05-12-2012 22:05, Jonathan M Davis wrote:

 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


Separate project? That kind of defeats the entire purpose: Making the 
to-be-tested module readily available to everyone...

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Dec 05 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Dec 05 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, December 05, 2012 22:52:09 Alex Rønne Petersen wrote:

 Separate project? That kind of defeats the entire purpose: Making the
 to-be-tested module readily available to everyone...


It makes sense to me to have a separate package in Phobos for stuff that has 
already been reviewed and is planned to be put into Phobos but we want to make 
sure that it's 100% solid before committing to its API permanently. It does 
not make sense to me to other stuff in there. That would be endorsing stuff
that 
isn't necessarily even close to a good enough state to go into Phobos. And how 
would you even decide what went in there? I really don't think that any kind 
of incubator project should go into Phobos-proper.

- Jonathan M Davis
Dec 05 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 05-12-2012 23:42, Jonathan M Davis wrote:

 On Wednesday, December 05, 2012 22:52:09 Alex Rønne Petersen wrote:

 Separate project? That kind of defeats the entire purpose: Making the
 to-be-tested module readily available to everyone...


 It makes sense to me to have a separate package in Phobos for stuff that has
 already been reviewed and is planned to be put into Phobos but we want to make
 sure that it's 100% solid before committing to its API permanently. It does
 not make sense to me to other stuff in there. That would be endorsing stuff
that
 isn't necessarily even close to a good enough state to go into Phobos. And how
 would you even decide what went in there? I really don't think that any kind
 of incubator project should go into Phobos-proper.

 - Jonathan M Davis


How do we decide, today, what goes into Phobos proper?

1. The community expresses some kind of common need.
2. There is universal agreement that the feature should be in Phobos.
3. Somebody takes the time to write a module for inclusion.
4. The module is submitted for review.
5. If review passes, the module is included; otherwise, it is refined 
and goto 4.

It's usually the community that drives the decisions about what's 
appropriate for Phobos and what isn't (i.e. at point 2). If we reach 
stage 3 in the aforementioned process, the module can be included in the 
staging package in Phobos proper for field testing if this is necessary 
before the initial review (this will obviously vary on a case-by-case 
basis).

If, after the staging period (say, 3 months AKA a release cycle), there 
is agreement that the module doesn't fit into Phobos after all (for 
whatever reason), it can simply be removed from the staging package. 
Otherwise, lessons learned from the staging period can be taken into 
account, the module refined, and submitted for review (point 4).

This seems like a perfectly sane model to me.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Dec 05 2012
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 5 December 2012 at 22:42:59 UTC, Jonathan M Davis 
wrote:

 On Wednesday, December 05, 2012 22:52:09 Alex Rønne Petersen 
 wrote:

 Separate project? That kind of defeats the entire purpose: 
 Making the
 to-be-tested module readily available to everyone...


 It makes sense to me to have a separate package in Phobos for 
 stuff that has
 already been reviewed and is planned to be put into Phobos but 
 we want to make
 sure that it's 100% solid before committing to its API 
 permanently. It does
 not make sense to me to other stuff in there. That would be 
 endorsing stuff that
 isn't necessarily even close to a good enough state to go into 
 Phobos. And how
 would you even decide what went in there? I really don't think 
 that any kind
 of incubator project should go into Phobos-proper.

 - Jonathan M Davis


That make sense to me. Isn't it what we are talking about here ?
Dec 05 2012
prev sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Wed, 5 Dec 2012, 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:

 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
 


 
 Separate project? That kind of defeats the entire purpose: Making the
 to-be-tested module readily available to everyone...


IMHO it must be separate to gain the speed and evolution that experimental 
suggests.  It should not be tied to the phobos release schedule.  
Additionally, the set of people should be separate (though could overlap).  
There's more downsides to being in the same repo and same release process 
as there are upsides, as far as I see it.

My 2 cents,
Brad
Dec 05 2012
prev sibling parent reply "Joshua Niehus" <jm.niehus gmail.com> writes:
On Wednesday, 5 December 2012 at 21:05:30 UTC, Jonathan M Davis 
wrote:

 But I think that that's completely inappropriate for putting 
 into Phobos.


I'd love to try out the new stuff if its convient enough...
I dont want to go jumping around github, pick up the "staging" 
material, put it into my current dev system and then play.
It would be *much* nicer if its part of Phobos
Dec 05 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 5 December 2012 at 22:32:14 UTC, Joshua Niehus 
wrote:

 It would be *much* nicer if its part of Phobos


We could always make non-phobos dev projects included in the dmd 
distribution zip... then the dev processes remain whatever and 
people still get them easily enough.
Dec 05 2012