• growler (35/35) Oct 06 2013 I've been watching the module review voting take place and I
• Dicebot (15/15) Oct 07 2013 I think that core issue with this proposal is that it stays too
• growler (3/18) Oct 07 2013 I like this proposal better, more streamlined.
• Rikki Cattermole (19/34) Oct 07 2013 I would like to build upon the dub idea and move phobos

"growler" <growlercab gmail.com> writes:

I've been watching the module review voting take place and I 
think we could benefit from two rounds of voting to get into 
Phobos.std.

Ideally, Phobos.std should consist of battle-hardened modules 
hopefully with some real-world testing. This is where Phobos.etc, 
or the suggested dub.stdx, could help. The timeline could be 
something like this:

0.Module proposed for Phobos.etc/dub.stdx, round 1 voting begins

1.First round: Vote for Phobos.etc/dub.stdx
  * Focus on API quality and whether it is needed for 
Phobos.etc/dub.stdx
  * If the API is sound then it can be accepted into Phobos.etc.

2.In Phobos.etc
  * Module sits in Phobos.etc/dub.stdx for 12 months from the 
*last API change* to gain battle experience.

  * Improving the implementation, code quality and real-world 
testing takes place in Phobos.etc and is encouraged.

  * API changes are not acceptable. If the API needs to be changed 
the existing module stays in Phobos.etc and the new API comes in 
as a new module at step 0.

3.DMD release time
  * All Phobos.etc/dub.stdx modules with 12-month old APIs are 
considered for proposal into Phobos.std.

4.Second round: Vote for Phobos.std
  * Focuses on the code/implementation quality and whether enough 
real-world testing has occurred.

5.Accept into Phobos.std!

D has a small user-base so real-world testing will of course be 
scant. But if a module sits for 12-months in a high profile 
peer-reviewed and officially endorsed library/repository then 
people are more likely to use it.

Also these comments are not a rant aimed at the work people are 
doing. All the work done is very good and of high standards IMO. 
It is just about the process and is all my opinion of course :D

Cheers!

"Dicebot" <public dicebot.lv> writes:

I think that core issue with this proposal is that it stays too 
far from actual Phobos development reality and described process 
is just too slow :) I am in favor of longer and more stable 
transitions but in 12 months even core Phobos modules may have 
API tweaks (not counting breaking compiler changes :P). It does 
not make much sense to go for safer module inclusion process when 
core language development still stays pretty close to bleeding 
edge.

I'd propose to go directly opposite way - very flexible dub 
packages in special category that get reviewed on regular basis 
and put onto vote once API is set in stone and used in such form 
for month or so. Voting to include into this category is 
unnecessary, it should be enough to simply conform certain style 
guidelines. After all, main goal is to get continuously reviewed 
and easily accessible module proposals.

"growler" <growlercab gmail.com> writes:

On Monday, 7 October 2013 at 12:01:38 UTC, Dicebot wrote:
 I think that core issue with this proposal is that it stays too 
 far from actual Phobos development reality and described 
 process is just too slow :) I am in favor of longer and more 
 stable transitions but in 12 months even core Phobos modules 
 may have API tweaks (not counting breaking compiler changes 
 :P). It does not make much sense to go for safer module 
 inclusion process when core language development still stays 
 pretty close to bleeding edge.

A fair point :D

 I'd propose to go directly opposite way - very flexible dub 
 packages in special category that get reviewed on regular basis 
 and put onto vote once API is set in stone and used in such 
 form for month or so. Voting to include into this category is 
 unnecessary, it should be enough to simply conform certain 
 style guidelines. After all, main goal is to get continuously 
 reviewed and easily accessible module proposals.

I like this proposal better, more streamlined.

"Rikki Cattermole" <alphaglosined gmail.com> writes:

On Monday, 7 October 2013 at 12:01:38 UTC, Dicebot wrote:
 I think that core issue with this proposal is that it stays too 
 far from actual Phobos development reality and described 
 process is just too slow :) I am in favor of longer and more 
 stable transitions but in 12 months even core Phobos modules 
 may have API tweaks (not counting breaking compiler changes 
 :P). It does not make much sense to go for safer module 
 inclusion process when core language development still stays 
 pretty close to bleeding edge.

 I'd propose to go directly opposite way - very flexible dub 
 packages in special category that get reviewed on regular basis 
 and put onto vote once API is set in stone and used in such 
 form for month or so. Voting to include into this category is 
 unnecessary, it should be enough to simply conform certain 
 style guidelines. After all, main goal is to get continuously 
 reviewed and easily accessible module proposals.

I would like to build upon the dub idea and move phobos 
completely into a dub package. With sub packages for individual 
parts. With the 'released' version of it  have dependencies on 
stable version versions of the sub packages. We can create sub 
packages for testing packages and make it dependent on an 
external repository where its development is actually happening.
It shouldn't be too hard to export a full set of sources and a 
library for distribution with e.g. dmd either. This also will 
allow us to focus upon modularisation and removal of inter 
dependency.

However this is a complete change to how we currently do it.
Another benefit is that phobos developers will be able to build 
and test whole tip versions of it with dub. Although disabling 
phobos inclusion by dmd may be an issue.

Because testing packages are pushed as a sub package that is not 
set as a dependency for phobos itself; it still has the name e.g. 
phobos:gui but it won't break code bases if its included into 
phobos later on.