New DIP73: D Drafting Library

[Dicebot via Digitalmars-d]

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.