Re: 2018-03 Commitfest Summary (Andres #1)

Hello,

> [...] The consequence of this appears to be that we should integrate
> everything that anybody decided worthy enough to review. That just
> doesn't make sense, we can't maintain the project that way, nor will the
> design be even remotely coherent.

Sure. The pgbench capabilities we are discussing are consistent, though,
which is why I'm arguing.

> Sure it's a balancing act, but nobody denies that.

Yep. I'm arguing on the balance.

>> So for me killing ready patches in the end of the process and on weak ground
>> can only make the process worse. The project is shooting itself in the foot,
>> and you cannot complain later that there is not enough reviewers.
>
> How would you want it to work otherwise? Merge everything that somebody
> found review worthy?

No, but I think that there should be stronger technical/design/... reject
arguments than the over-conservatism shown on some patches.

I'll take as an example the pgbench hash functions patch about which you
seemed to show some reservation: it adds a few hash functions, a necessary
feature to reproduce a YCSB load (Yahoo cloud service benchmark), together
with zipfian distributions (already accepted, thanks).

Why would committers prevent pgbench to be used to reproduce this kind of
load? The point of pgbench is to be able to test different kind of
loads/scenarii... Accepting such features, if the implementation is good
enough, should be no brainer, and alas it is not.

> Have everything immediately reviewed by committers? Neither of those
> seem realistic.

Sure. I'm aiming at an ambitious "eventually":-)

Note that I'd wish that at least the ready-for-committer bug-fixes would
be processed by committers when tagged as ready in a timely fashion (say
under 1 CF), which is not currently the case.

--
Fabien.