On 16/12/14 04:57, Noah Misch wrote: >> But that doesn't mean we should be turning anyone away. We should not. > > +1. Some of the best reviews I've seen are ones where the reviewer expressed > doubts about the review's quality, so don't let such doubts keep you from > participating. Every defect you catch saves a committer time; a review that > finds 3 of the 10 defects in a patch is still a big help. Some patch > submissions waste the community's time, but it's almost impossible to waste > the community's time by posting a patch review. > > Confusion may have arisen due to statements that we need more expert > reviewers, which is also true. (When an expert writes a sufficiently-complex > patch, it's important that a second expert examine the patch at some point.) > If you're a novice reviewer, your reviews do help to solve that problem by > reducing the workload on expert reviewers.
I should add that by reducing the barrier of entry for patch review, there is definitely potential to find common errors before a patch gets analysed in detail by a committer. For example I may not know a lot about certain PostgreSQL subsystems but from a decent C coding background I can pick out certain suspicious things in patches, e.g. potential overflows, pointer arithmetic bugs, spelling mistakes/incorrect comments etc. and flag them to the original submitter to double-check. ATB, Mark. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
