Hi Dicebot.

You are a clear thinker - close reasoning - and I admire that.

> As you may see requirements are very lax. Only real difference is that your proposal 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

Isn't there a psychological barrier to submitting pulls for someone else's source code when it is not clear it will be welcome?  Plus encouraging others to write docs etc. A community project will still be de facto owned by the author, but perception of its status is clearer.

Any benefit from Mars would come from purely human factors, but sometimes these are important.


Laeeth.

On Thursday, 5 February 2015 at 23:04:03 UTC, Laeeth Isharc wrote:
>>If it's worth inclusion in phobos, it will rise to the top.
>
> I admire idealists, but in the past few years how many independent projects have been adopted by phobos?  Is it the case that none of those that were not are essentially at core unworthy of adoption, or is it that they need some polishing to be of more general use and doing so simply doesn't appeal to the library author, whilst others with the skills are less inclined to help on a private project?  I don't know the answer, but obviously have a tentative assessment.

Despite you mixed up many posts in the one answer I like most of you points.

> Since there is so much hidden gold in dub, I wonder if it makes sense to ask notable library authors how they might feel about adoption of parts of their work into Mars.  What does Adam Ruppe think, for example?

+1

>> Maybe I'm wrong but there is a big controversy and fragmentation e.g. in
>> database and gui domain.
>
> So don't start with databases and guis.  And at least down the line consider the possibility that there might not be just one option when the needs of the problem domains may be very different in spite of apparent superficial technical similarity.


I mean I want to have a functionality in D like in Qt, i.e.  gui for:
-Windows
-Linux
-Android

This would need a huge amount of work.

I don't need it to be ready in the first release though. Also I don't mind to have it changing rapidly in the first stage of development.

>> Moving things towards phobos won't help with fragmentation, will just piss
>> those off who disagree.  Better path is to put solutions in dub for people
>> to use and abuse, see if one becomes dominant.  Only then look at moving to
>> phobos.
>
> If Mars doesn't accomplish its goals then people won't use it and all that will have happened is a little wasted effort - but one doesn't learn without experimentation, including in the social domain.   It just hasn't happened that people mystically converge on a solution just because it is in dub, polish the code and write documentation for somebody else's code base - possibly because someone needs to lead the effort.

The idea seems to be cheep in implementation (e.g. just creating the official project would be something) and can be reverted any time as it won't be any kind of dependency.

>> This may lead to competing packages. How would we decide what are the
>> "proper" packages.
>
> One might start with exploring what is already out there and seeing which authors are agreeable to having their work adopted.  Making decisions isn't easy in life, and people are going to criticize you because not everyone will be happy with the outcome - but that isn't a reason not to do something if it is worth doing.

+1
For me, the issue is high entry barrier for Phobos. OTOH I can imagine myself making pull requests for the drafting library. Not mentioning testing the progress.


>> I like the idea of having a 'recommended' section in dub, for those things
>> considered by the community to be good.
>
> This is a start, but doesn't address the problem that to be useful to a broad audience one needs much more than raw code and that the library author may not want to or be good at doing these other things.

+1

http://wiki.dlang.org/DIP73#Comparison_to_code.dlang.org_packages

Piotrek

On Thursday, 5 February 2015 at 18:23:19 UTC, Zach the Mystic wrote:
>> 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
>
> It seems to me that number 2 is wrong. It doesn't matter what is generally desired. The final say depends completely on the leadership. Yes or No has to come from above. Or am I wrong about this?

No, you get it wrong. This is decided exclusively community voting. Andrei or Walter can veto something that they don't want but their explicit approval is not required.

On Thursday, 5 February 2015 at 22:04:04 UTC, Jeremy Powers wrote:
> Snipped a bit, tl;dr is you should use dub.

I use it but with no success in the matter of the proposal.

> How could you be sure that after long lonely work the proposal is worth
>> inclusion?
>>
..
>
> If it's worth inclusion in phobos, it will rise to the top.

I actually don't know how to comment that in regards to the DIP. I don't recall dedicated protects for particular modules.


> Maybe I'm wrong but there is a big controversy and fragmentation e.g. in
>> database and gui domain.
>
>
> Moving things towards phobos won't help with fragmentation, will just piss
> those off who disagree.

Any example of existing Phobos modules (added recently)?

> I like the idea of having a 'recommended' section in dub, for those things considered by the community to be good.  I don't think anything  should even
> think about phobos inclusion (even on-path-to-inclusion) until it has been used and abused enough.

I don't have nothing against. But IMO this won't solve the problem with standardization of functionality. From the perspective of usual user.

> We have this nice package system for non-phobos stuff, should leverage it.

The functionality of dub is not related to the DIP. I tried to keep it as a separate topic.

Piotrek

On Thursday, 5 February 2015 at 23:35:04 UTC, Dicebot wrote:
> On Thursday, 5 February 2015 at 18:23:19 UTC, Zach the Mystic wrote:
>>> 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
>>
>> It seems to me that number 2 is wrong. It doesn't matter what is generally desired. The final say depends completely on the leadership. Yes or No has to come from above. Or am I wrong about this?
>
> No, you get it wrong. This is decided exclusively community voting. Andrei or Walter can veto something that they don't want but their explicit approval is not required.

I'm surprised. From my point of view, yours is a bad strategy. What bothers me is how could a module just take Walter or Andrei completely by surprise and still end up in the standard library? I honestly wouldn't want that, and yet apparently it's possible. Now don't get me wrong. I do think listening to the community is critical, and allowing a new module because of overwhelming popular demand is also acceptable, provided there's no reason to veto it.

But to me, that veto means a whole lot. It means that people can't know what will be rejected or accepted unless told, and in the absence of being told, the motivation to work on something may dry up. That's what I'm trying to prevent by my strong insistence on the necessity of leadership.

The way I see it, the conversation about what is suitable for a standard library should come first. Someone should propose something, get a signal on prospects for inclusion, and then use that signal do determine whether to keep developing the library for phobos or not. Without the signal, how will they know whether to develop it for phobos or just for their own 3rd-party use? How do you get a clear signal when the module is only voted on at the *end* of the process?

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.

On 2/5/15 4:08 PM, Zach the Mystic wrote:
> On Thursday, 5 February 2015 at 23:35:04 UTC, Dicebot wrote:
>> No, you get it wrong. This is decided exclusively community voting.
>> Andrei or Walter can veto something that they don't want but their
>> explicit approval is not required.
>
> I'm surprised. From my point of view, yours is a bad strategy. What
> bothers me is how could a module just take Walter or Andrei completely
> by surprise and still end up in the standard library? I honestly
> wouldn't want that, and yet apparently it's possible. Now don't get me
> wrong. I do think listening to the community is critical, and allowing a
> new module because of overwhelming popular demand is also acceptable,
> provided there's no reason to veto it.

D is a collaborative project and it's obvious that at some point control and trust need to be distributed to foster faster growth and broader participation.

Walter and I have been occasionally appalled by stuff that made it in Phobos - as was this recent case with @trusted functions that can't be trusted nonsense - but by and large the good overwhelms the not-so-good. I trust close contributors who have historically done good work to continue doing so, and we can delegate certain tasks to folks. As a simple example I trust Martin and Rainer to do good work on the GC and review each other's work.

> But to me, that veto means a whole lot. It means that people can't know
> what will be rejected or accepted unless told, and in the absence of
> being told, the motivation to work on something may dry up. That's what
> I'm trying to prevent by my strong insistence on the necessity of
> leadership.

It is clear we have historically a less than stellar record of good leadership. We plan to improve dramatically on that starting January - of this year :o) - and there are a few good early signs that we hope will develop into successful patterns.

There's no need to fear rejection. There's always code.dlang.org and as I said: you can trust me to recognize great work when I see it. So there's definitely no need to ask for permission.

One thing we'll try more of is being more decisive instead of letting options linger forever. Sometimes we just say "we support this" or "we don't support that" and our quest for the community is to understand that "no" is sometimes necessary for focusing on the "yes".

> The way I see it, the conversation about what is suitable for a standard
> library should come first. Someone should propose something, get a
> signal on prospects for inclusion, and then use that signal do determine
> whether to keep developing the library for phobos or not. Without the
> signal, how will they know whether to develop it for phobos or just for
> their own 3rd-party use? How do you get a clear signal when the module
> is only voted on at the *end* of the process?

Just use code.dlang.org. It's perfect either as a place for good work and a stepping stone toward the standard library.


Andrei

Perhaps it is over ambitious to start with the goal of producing only code destined to end up in Phobos.  The domain is so broadly defined, and the standard to aspire to so high that one ends up setting the goalpost so high that given likely contributors one risks ending up running out of steam before getting very far.  Also, the domain of things that maybe should never be in Phobos but are nonetheless important and lack a well documented, industrial strength solution - this domain is not tiny.

Maybe biting off a small chunk so you can show what you mean, and understand in practical terms what is involved might be the first step on a longer journey.  That's actually realistically how one would have to approach it anyway even were you to get universal buy-in, which doesn't seem to be on the cards.  It is easier to convince people as momentum picks up than with just an idea.

Pick something not too large but useful and start working on it ?

On Friday, 6 February 2015 at 00:45:16 UTC, Andrei Alexandrescu
wrote:
> On 2/5/15 4:08 PM, Zach the Mystic wrote:
>
> Just use code.dlang.org. It's perfect either as a place for good work and a stepping stone toward the standard library.
>
> Andrei

I get the feeling you guys will eventually look back at this idea
to revive it in some way. Im no oracle though, just saying...