does it scale to have 1 person approve of all phobos additions?

[H. S. Teoh]

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.