Re: 2018-03 Commitfest Summary (Andres #1) - Mailing list pgsql-hackers

Hello Andres,

> [...] I find that is a fairly absurd, and frankly insulting, ascription 
> of motives.

I do not thought that I was insulting anyone, and I apologise if anyone 
felt insulted by my message.


> I didn't "veto" the patch or anything, nor did Tom.

Good. My past experience is that if Tom shows a reservation against the 
purpose of a patch, the patch is nearly dead, so I interpret that as a 
veto, even if it is not strictly one.


> I wondered whether we're adding more cost than overall gains.  We have 
> very few people that actually show up when there are bugs and fix them, 
> and adding more code tends to make maintenance harder.

As far as pgbench is concerned, I've been doing most of the maintenance, 
but it necessarily involves a committer in the end, obviously.


> A lot of contributors, including serial ones, don't even remotely put in 
> as much resources reviewing other people's patches as they use up in 
> reviewer and committer bandwidth. You certainly have contributed more 
> patches than you've reviewed for example.

Please check your numbers before criticising someone unduly.

Last time I checked I was more than even. According to the last three CF 
data, it seems that I'm quite okay over one year:

  2018-01: 4 submitted vs 7 reviewed
  2017-11: 8 submitted vs 7 reviewed
  2017-09: 8 submitted vs 12 reviewed
  2017-03: 5 submitted vs 3 reviewed

Total: 25 "submitted" and 29 reviewed.

I am counting patches I submitted which can stay "ready" over half a dozen 
CF as half a dozen submissions, which is not that to the count, because 
they were not new submissions to the CF and they did not require any 
reviewing on the CF where they stay put. I'm not sure that bug fixes 
should really be counted either.

Basically, I'm spending much more time reviewing & testing than 
developing. The patch I submit are usually pretty small and low impact, 
with exception. I tend to review similar patches, which seems fair.


> That fundamentally can't scale, unless some individual contribute way 
> more review resources than they use up, and that's not something many 
> people afford nor want.

Hmmm. Sure. Please note that it is what I think I am doing:-)

Now, if you feel that my overall contribution is detrimental to the 
project, feel free to ask me to stop contributing so as to help it, which 
is my primary objective anyway.


> And while possibly not universally seen that way, in my opinion, and I'm
> not alone seeing things that way, contributors that contribute more
> review resources than they "use", are granted more latitude in what they
> want to do because they help the project scale.

Sure.

> Note that pgbench code does add work, even if one is not using the new 
> features. As you know, I was working on performance and robustness 
> improvements, and to make sure they are and stay correct I was 
> attempting to compile postgres with -fsanitize=overflow - which fails 
> because pgbench isn't overflow safe. I reported that, but you didn't 
> follow up with fixes.

Indeed. AFAICR you did it before, I think that I reviewed it, it was not a 
period for which I had a lot of available time, and I did not feel it was 
something that urgent to fix because there was no practical impact. I 
would have done it later, probably.

-- 
Fabien.