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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
