On Sun, Dec 14, 2014 at 4:53 PM, Mark Cave-Ayland <mark.cave-ayl...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
