Re: [9.4 CF 1] The Commitfest Slacker List

On Thu, Jul 04, 2013 at 08:08:57PM +1200, Mark Kirkwood wrote:
> On 04/07/13 10:43, Robert Haas wrote:
>
>> And
>> people who submit patches for review should also review patches: they
>> are asking other people to do work, so they should also contribute
>> work.
>>
>
> I think that is an overly simplistic view of things. People submit
> patches for a variety of reasons, but typically because they think the
> patch will make the product better (bugfix or new functionality). This
> is a contribution in itself, not a debt.

True. I don't see that policy as a judgment against the value of submissions,
but rather a response ...

> Now reviewing is performed to ensure that submitted code is *actually*
> going to improve the product.
>
> Both these activities are volunteer work - to attempt to tie them
> together forceably is unusual to say the least. The skills and
> experience necessary to review patches are considerably higher than
> those required to produce patches, hence the topic of this thread.
>
> Now I do understand we have a shortage of reviewers and lots of patches,

... to this. Reviewing may be harder than writing a patch, but patch
submitters are more promising as reviewers than any other demographic. The
situation has a lot in common with the system of academic peer review:
http://en.wikipedia.org/wiki/Peer_review#Scholarly_peer_review

It's a good value for submitters. By the time my contributions are part of a
release, they've regularly become better than I would have achieved working in
isolation. Reviewers did that.

> and that this *is* a problem - but what a wonderful problem...many open
> source projects would love to be in this situation!!!

A database is different from much other software in that users build
intricate, long-lived software of their own against it. In that respect, it's
like the hardware-independent part of a compiler or an OS kernel. When we
establish an interface, we maintain it forever or remove it at great user
cost. It's also different by virtue of managing long-term state, like a
filesystem. That dramatically elevates the potential cost of a bug. A
spreadsheet program might reasonably have a different perspective on a surge
of submissions. For PostgreSQL, figuring out how to review them is key.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com