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.
