On Sun, Dec 14, 2014 at 4:53 PM, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> What I find frustrating is that I've come back from a workflow where
> I've been reviewing/testing patches within months of joining a project
> because the barrier for entry has been so low, and yet even with much
> longer experience of the PostgreSQL codebase I feel I can't do the same
> for patches submitted to the commitfest.
>
> And why is this? It's because while I know very specific areas of the
> code well, many patches span different areas of the source tree of which
> I have little and/or no experience, which when supplied as a single
> monolithic patch makes it impossible for me to give meaningful review to
> all but a tiny proportion of them.
So, there are certainly some large patches that do that, and they
typically require a very senior reviewer. But there are lots of small
patches too, touching little enough that you can learn enough to give
them a decent review even if you've never looked at that before. I
find myself in that situation as a reviewer and committer pretty
regularly; being a committer doesn't magically make you an expert on
the entire code base. You can (and I do) focus your effort on the
things you know best, but you have to step outside your comfort zone
sometimes, or you never learn anything new.
I feel like we used to be better at encouraging people to participate
in the CF even if they were not experts, and to do the best they can
based on what they did know. That was a helpful dynamic. Sure, the
reviews weren't perfect, but more people helped, and reviewing some of
the patch well and some of it in a more cursory manner is way better
than reviewing none of it at all.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
