2-round Phobos.std voting process

[Rikki Cattermole]

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.