Re: [9.4 CF 1] The Commitfest Slacker List

On 25/06/13 15:56, Tom Lane wrote:
> Mark Kirkwood <mark.kirkwood@catalyst.net.nz> writes:
>> One of the reasons for fewer reviewers than submitters, is that it is a
>> fundamentally more difficult job. I've submitted a few patches in a few
>> different areas over the years - however if I grab a patch on the queue
>> that is not in exactly one of the areas I know about, I'll struggle to
>> do a good quality review.
>
>> Now some might say "any review is better than no review"... I don't
>> think so - one of my patches a while was reviewed by someone who didn't
>> really know the context that well and made the whole process grind to a
>> standstill until a more experienced reviewer took over. I'm quite wary
>> of doing the same myself - anti-help is not the answer!
>
> FWIW, a large part of the reason for the commitfest structure is that
> by reviewing patches, people can educate themselves about parts of the
> PG code that they don't know already, and thus become better qualified
> to do more stuff later.  So I've got no problem with less-experienced
> people doing reviews.
>
> At the same time, it *is* fair to expect someone to phrase their review
> as "I don't understand this, could you explain and/or improve the
> comments" rather than saying something more negative, if they aren't
> clear about what's going on.  Without some specific references it's hard
> to be sure if the reviewer you mention was being unreasonable.
>
> Anyway, the point I'm trying to make is that this is a community effort,
> and each of us can stand to improve our knowledge of what is fundamentally
> a complex system.  Learn something, teach something, it's all good.
>

Yes - the reason I mentioned this was not to dig into history and bash a 
reviewer (who was not at all unreasonable in my recollection)... but to 
highlight that approaching a review is perhaps a little more complex and 
demanding that was being made out, hence the shortage of volunteers.

However I do completely agree, that encouraging reviewers to proceed 
with the approach you've outlined above seems like "the way". And yes - 
it is going to be a good way to get to know the code better.

Regards

Mark