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

[Andrei Alexandrescu]

On 03/20/2018 06:56 PM, Meta wrote:
> Does it make sense? In my opinion, no, but according to Andrei be has 
> tried being less hands-on before and it resulted in measurably worse 
> quality code in Phobos; thus, he re-established himself as the 
> gatekeeper. I agree that it doesn't scale and think that at this point, 
> it's probably actively hurting Phobos because a lot of good work sits 
> for so long and eventually becomes abandoned.
> 
> 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.

Thanks for this comment (which is eerily accurate), and thanks Timothee 
for raising the matter.

It is an ongoing burden to be the decider on new API additions to 
Phobos; indeed I have taken this responsibility because I have attempted 
to relinquish it in the past, with negative results. It is definitely 
not something that I prefer or enjoy, and am permanently on the lookout 
for people with similar design sensibilities to share the burden with. 
The door is open, if not kicked off its hinges. Please take note!

That said, the question of scalability is a bit misplaced. API additions 
to Phobos are rare and long-lasting; it is entirely appropriate to let 
them ripe a little. In contrast, various improvements to Phobos - over 
100 of them - only need good reviews, and are obviously bottlenecked by 
our general lack of reviewers. That's our real bottleneck. It seems 
appropriate to ask the question why we'd ask for acceleration of API 
additions without improving response for other work.

I just reviewed https://github.com/dlang/phobos/pull/6178. As I'd 
expected, it's good work - which is exactly the matter. Good work in a 
submission means most review work. It's not bad work, which can be 
easily rejected. And it's not brilliant work, which can be easily 
accepted. The PR has bugs and quality issues that any reviewer could 
find and provide feedback on. It's not in the state where it's 
bottlenecked by just a stamp of approval.

Naming is a matter I wanted to defer having a debate on. We should call 
the facility staticArray to prevent an imaginary conversation like this:

Q: "So I have a range here, how do I get an array from it?"

A: "Easy, just append .array to it and you're done."

Q. "Cool! Now I need a static array. Wait! Don't tell me, don't tell 
me... staticArray is what I should look for!"

A: "Um, no, sorry. That's called asStatic."

Besides, [1,2].asStatic may be guessed right by a reader, but 
myrange.asStatic!2 most likely not.


Thanks,

Andrei