Re: Commitfest problems - Mailing list pgsql-hackers

On 16/12/14 07:33, David Rowley wrote:

> On 16 December 2014 at 18:18, Josh Berkus <josh@agliodbs.com
> <mailto:josh@agliodbs.com>> wrote:
> 
>     > Man. You're equating stuff that's not the same. You didn't get your way
>     > (and I'm tentatively on your side onthat one) and take that to imply
>     > that we don't want more reviewers.
> 
>     During that thread a couple people said that novice reviewers added no
>     value to the review process, and nobody argued with them then.  I've
>     also been told this to my face at pgCon, and when I've tried organizing
>     patch review events.  I got the message, which is why I stopped trying
>     to get new reviewers.
> 
>     And frankly: if we're opposed to giving credit to patch reviewers, we're
>     opposed to having them.
> 
> 
> 
> I'd just like to add something which might be flying below the radar of
> more senior people. There are people out there  (ike me)  working on
> PostgreSQL more for the challenge and perhaps the love of the product,
> who make absolutely zero money out of it. For these people getting
> credit where it's due is very important. I'm pretty happy with this at
> the moment and I can't imagine any situation where not crediting
> reviewers would be beneficial to anyone.

This is exactly where I am at the moment, having previously been more
involved with the development side of PostgreSQL during the past.

Personally having a credit as a patch reviewer isn't particularly
important to me, since mail archives are good enough these days that if
people do query my contributions towards projects then I can point them
towards any reasonable search engine.

The biggest constraint on my ability to contribute is *time*.

Imagine the situation as a reviewer that I am currently on the mailing
list for two well-known open source projects and I also have a day job
and a home life to contend with.

For the spare time that I have for review, one of these projects
requires me to download attachment(s), apply them to a git tree
(hopefully it still applies), run a complete "make check" regression
series, try and analyse a patch which will often reference parts to
which I have no understanding, and then write up a coherent email and
submit it to the mailing list. Realistically to do all this and provide
a review that is going to be of use to a committer is going to take a
minimum of 1-2 hours, and even then there's a good chance that I've
easily missed obvious bugs in the parts of the system I don't understand
well.

For the second project, I can skim through my inbox daily picking up
specific areas I work on/are interested in, hit reply to add a couple of
lines of inline comments to the patch and send feedback to the
author/list in just a few minutes.

The obvious question is, of course, which project gets the majority
share of my spare review time?


ATB,

Mark.