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!
