On Thursday, 5 February 2015 at 06:56:52 UTC, Dicebot wrote:
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.
No need to be sorry. D needs quality guards.
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
When you say I put the current process wrongly, you mean there is
no way to submit a new module avoiding a std.experimental
namespace? Or something else? Can you provide a link to the
latest official description? I will update the pictures.
2) It must implement something generally desired in Phobos
Which is?
3) Implementation is supposed to be at least stable enough to
not undergo a full rewrite after inclusion. Major API changes
are acceptable.
This point is one of the main problems the DIP tries to avoid.
According to your statement the module should be almost complete
before the pull request is accepted. I mean without any design
flows. In many cases that is really hard to achieve for one
developer (e.g gui).
OTOH if you don't see the full implementation and can't test it
you may not see the fundamental flows in design.
Of course this may be doable for less complex modules. Then the
current way of using std.experimental alone may be applicable.
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.
How could you be sure that after long lonely work the proposal is
worth inclusion?
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
How do you know what modules should not be in Phobos? Is there
any widely accepted list? Even C++ is getting more "open minded".
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
Maybe I'm wrong but there is a big controversy and fragmentation
e.g. in database and gui domain.
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
This may lead to competing packages. How would we decide what are
the "proper" packages. There can be impossible to fully control
the development by the whole community (yes I know I repeat
myself).
In general, there needs to be a good analysis backing the
proposal to change anything - good intention and good idea
alone are not enough.
Fully agree. Of course I provided only ideas based on my personal
experience and NG posts. Any hint what else I could do is welcome.
It is better to do nothing than do something unless one is
extremely sure that it will help.
I guess there is always risk there. But I agree that we should be
convinced about the progress beforehand.
Piotrek
