On Thursday, 5 February 2015 at 19:05:10 UTC, Piotrek wrote:
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?
Yes, right now this is the idea. All new modules must stay some
time in std.experimental to stabilize (unless they are simply
renaming or split of existing modules).
Can you provide a link to the latest official description? I
will update the pictures.
Sadly, no, and this is largely my fault. Existing description
(http://wiki.dlang.org/Review/Process) was written by previous
review queue manager. During last few reviews I have managed
plenty of things has changed (including addition of
std.experimental) but wiki description wasn't updated.
I will need to update that. Main problem is that it is still a
rapidly changing target and I am not sure current scheme is final.
2) It must implement something generally desired in Phobos
Which is?
Decided by community voting as part of formal reviews process.
One of questions for voting is "Do you want to see this
functionality 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.
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.
I disagree that those are "many cases". In fact, it applies to
only few really big libraries like ones that deal with GUI or
databases - all kind of stuff that is inherently controversial
and can't be officially endorsed anyway.
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?
Because it gets destroyed by many reviewers - in great detail.
And if formal review thread does not get enough contribution from
to-be-users, it is likely to be rejected. AFAIR I had to halt
review of std.signal replacement because of that, until it gets
more interest from community.
How do you know what modules should not be in Phobos? Is there
any widely accepted list? Even C++ is getting more "open
minded".
You decide that, among all other voters. Opinion of existing
Phobos developers naturally is considered of more importance
during the voting though (I publish separate stats).
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.
Yes, and it will always stay so because of inherent nature of
such domains. People won't start using libraries they don't like
simply because those are marked as "official". Clearly not in D
community, we like our reinvented wheels :)
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).
No different from deciding what goes to Phobos or deciding what
goes to your proposed library.
