On Tue, Mar 20, 2018 at 10:56:00PM +0000, Meta via Digitalmars-d wrote: [...]
> On the other hand, it could become much worse for Phobos if he was entirely hands off and delegated its shepherding to a larger group of core contributors. A balance has to be struck somewhere... Maybe a hypothetical group like this needs to be trained by Andrei such that he can trust them to properly guide Phobos' development, and will only come to him with the really big, important stuff.

I've brought this up before.  IMO, there is insufficient trust given to contributors, usually for good reasons, but with the bad consequence that things keep getting held up.  The only viable solution that I can see is like you said: Andrei needs to select a group of people he trusts, and train them so that they will make decisions to his liking. Then trust them to make the right decisions and let them do their job.

This model has been proven to work, e.g., in the Linux kernel, where even though Linus still has the final say on things, most of the work is done by trusted delegates, each of whom is responsible for specific areas that they have expertise in (and where Linus trusts their judgment), and not everything requires personal attention from Linus. Without that delegation, Linux would have remained a hobby project, and would never have become what it is today.

A similar approach could be adopted for Phobos. In some sense it somewhat already has, but it could be increased.  For example, Jonathan Davis is pretty much the go-to person for decisions on std.datetime, and Dmitry Olshansky is the go-to person for std.regex and std.uni.  There are a few more, but those are the most obvious ones that come to mind. If more could be involved in more areas, it would help things.


On the flip side, though, I think it's unfair to put all the blame on Andrei.  The fact of the matter is that Phobos is big -- far too big given the number of active contributors.  IME, 90% of PR activity is centered around a small number of core modules like std.algorithm, std.range, std.stdio, std.format, std.typecons, and multiple people feel competent enough to review PRs in these areas.  So PRs in these modules generally get well-reviewed and merged within a relatively reasonable timeframe.

But outside of this core group of modules, people are less comfortable to review -- I, for one thing, would tend to avoid reviewing PRs to modules that I don't use, simply because I don't use it and therefore wouldn't know off-hand what might or might not be a good decision for that module.  The problem is that almost every other Phobos dev also feels the same way.  And given the sheer size of Phobos, there are a large number of such modules that most of us are afraid to touch because we don't feel confident enough to oversee it.  And whoever wrote the original code has long since moved on, or is otherwise too busy, so PRs will just sit there unattended.

I don't have any good solutions for how to fix this problem, besides what everyone is probably already tired of hearing. (Start contributing, develop a thick skin and a stubborn persistence to keep pushing things until they get through. Make yourself heard. Make yourself one of the trusted delegates so that you can actually do something about all this.)


> By the same measure, I feel that Walter is becoming a bottleneck on dmd development and maybe a similar solution is necessary.

I haven't been too involved with dmd development, but AFAICT this isn't strictly true.  I've had a few PRs merged into dmd without going through Walter.  Though it is true that the dmd PR queue needs some serious love.  Losing Kenji a few years ago was a silent, but major loss to D, esp. to dmd development.  To this day I still miss his seemingly tireless stream of dmd bugfixes and improvements.  :-(

Having said that, though, some of the older dmd PRs do involve fairly tricky and complicated changes, and it should not be a surprise that it's hard to make a decision on those issues.  This has to be taken into consideration, beyond just looking at the outward size of the PR queue.

Furthermore, a good number of dmd PRs *are* being merged every day, so I think it's a bit unfair to accuse Walter of slowing things down, much as I agree that the process could be improved.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

On Tue, 2018-03-20 at 15:09 -0700, Timothee Cour via Digitalmars-d wrote:
> 
> […]

> * if phobos is supposed to be batteries included
> […]

Perhaps the lesson of Python, which always used to be "batteries included", but now clearly is not, especially given PyPI, is that D/Phobos should not be "batteries included".

Go, Ceylon, and Rust are clearly going the route of "no way is the distribution batteries included, but look at the repositories for the good stuff". Go relies on DVCS only. Ceylon and Rust have Herd and crates.io respectively as central semi-managed repositories. And Rust supports DVCS.

D has the Dub repository, so why is Phobos being "batteries included" even an issue now?

-- 
Russel.
==========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wednesday, March 21, 2018 09:45:46 Russel Winder via Digitalmars-d wrote:
> D has the Dub repository, so why is Phobos being "batteries included" even an issue now?

Some folks seem to think that something _has_ to be in the standard library, or the language is sub-standard, and some folks just want things to be in the standard library. So, it still comes up in conversations from time to time that X or Y should be in Phobos, but since folks aren't writing such modules and then attempting to get them into Phobos, it's largely a moot issue at the moment.

Also, as code.dlang.org has become more prevalent, attempts to get new modules into Phobos have mostly disappeared.

Once I feel that dxml is ready, I'll probably try and get it into Phobos to replace std.xml, but the only reason that I intend to do that is because std.xml is not considered to be up to Phobos standards, and we've wanted to replace it for years now. If there were no XML module in Phobos, I wouldn't propose one. It doesn't necessarily hurt to have such a thing in Phobos, but it's far from necessary.

I suspect that the main reason that we haven't seen more attempts to get stuff into Phobos is that folks simply don't want to go through the Phobos review process, and because they can now easily make it available on code.dlang.org, there's a lot less incentive to try and get it into Phobos just to make it available to others. I think that at this point, the main advantage to having something in Phobos relates to vetting.

Any major functionality that has gone into Phobos has been reviewed by some of the core D developers. How thoroughly it's reviewed varies, and there's some risk of a new addition winning a vote, because folks want the functionality, so they vote yes, but they didn't take the time to actually review the code, but it has gotten _some_ review, which most code on code.dlang.org has not, and in general, the stuff that goes through the Phobos review process has been pretty thoroughly reviewed. So, the code quality has a stamp of approval on it that stuff on code.dlang.org doesn't have, and by something being the "official" implementation, in principle, you can rely on it being good for the majority of use cases and generally being a well-designed, solid solution. If the standard library has a solution for your problem, then you can just use that and don't have to go looking elsewhere unless you later find that something about your program makes it so that Phobos' solution isn't going to work for you, whereas if there's no solution in Phobos, you'll have to go digging for stuff on code.dlang.org and spend the time to evaluate each possible solution.

So, from that perspective, there's some value in having something in Phobos instead of on code.dlang.org. Ultimately, it doesn't scale. Even a "batteries included" solution doesn't contain everything, and often enough, there are enough ways to solve a problem that a "one size fits all" solution isn't going to work, but you can get a lot of functionality in there as long as we have the manpower and process to maintain it. However, it's questionable that we have the manpower, and this thread was started precisely because of concerns about the process.

And ultimately, I agree that there isn't that much stuff that needs to be in Phobos. code.dlang.org fulfills the role just fine for most stuff, and as improvements come to code.dlang.org, that will work better and better. What ultimately gets into Phobos is going to largely depend on what gets proposed for inclusion, and based on what's been happening, I suspect that the debate is mostly going to take care of itself in that not much new stuff is going to be proposed for inclusion in Phobos, meaning that discussions about stuff that someone thinks should be in D's standard library are mostly going to be complaints about something not being there that that particular person thinks should be there and not actual discussions about whether a piece of functionality that exists should go in there or not.

- Jonathan M Davis