You have clearly put a lot of effort in this. That makes me very
uneasy to repeat the same critique as earlier but, sadly, it
still all applies. This proposal tries to fix problems it doesn't
prove exist, doing so with solutions that are not guranteed to
help.
It also wrongly explains current process of inclusion into Phobos
in general and specifically std.experimental - being probably one
of more involved persons with Phobos review queue I feel like
this needs to be explained.
Considering all the discussion that happened during
std.experimental.logger I understand that we have settled with
pretty much this:
1) All Phobos proposals must go through std.experimental.logger
2) It must implement something generally desired in Phobos
3) Implementation is supposed to be at least stable enough to not
undergo a full rewrite after inclusion. Major API changes are
acceptable.
4) Before DMD/Phobos release is made existing packages that feel
stable can undergo a formal review for inclusion in Phobos main
package
With that in mind initial public review is supposed to only
determine if (2) and (3) is true which is mostly a formality as
people rarely propose modules they are not serious about.
As you may see requirements are very lax. Only real difference is
that your poposal allows to accept modules that are not supposed
to ever go to Phobos at all - which I am still convinced is a bad
thing and belongs to code.dlang.org
Speaking about objections vs code.dlang.org
community driven development as opposed to individually driven
(ownership/control of the source code)
see no reason to expect this is actually better of makes any
notable difference in general
out of the box readiness
dub is planned to be distributed with DMD
wide range of community members involved in the development to
reduce controversy and fragmentation staring from the initial
stage
no idea where this even comes from
Pretty much all extra goodies from DIP73 can be implemented by
creating special "officially endorsed" category in code.dlang.org
and showing it as a default package list at code.dlang.org front
page
In general, there needs to be a good analysis backing the
proposal to change anything - good intention and good idea alone
are not enough. It is better to do nothing than do something
unless one is extremely sure that it will help.
