Re: Commitfest problems - Mailing list pgsql-hackers

From Mark Cave-Ayland
Subject Re: Commitfest problems
Date
Msg-id 549008C1.7050202@ilande.co.uk
Whole thread Raw
In response to Re: Commitfest problems  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Commitfest problems  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
On 15/12/14 19:27, Robert Haas wrote:

> 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.

Right. Which is why I'm advocating the approach of splitting patches in
relevant chunks so that experts in those areas can review them in
parallel. And even better, if I then want to start digging into other
parts of the system as time and interest allow then I can choose to
begin by picking a subject line from a patchset and going through this
small individual patch in detail rather than a single large patch.

It has often been suggested that people learn best when studying a mix
of 80% of things they already know compared to 20% of things they don't.
At least with more granular patches people can find a comfortable ratio
of new/old material vs. a single large patch which could be 70-80% of
completely new material and therefore much more difficult to pick-up.

Another thought to ponder here is that by reviewing smaller patches
which takes less time, for the same time cost a reviewer with experience
in one specific area can in theory review and provide feedback on
another 2-3 patchsets which should help relieve patch review starvation
across patchset submissions.


ATB,

Mark.




pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Commitfest problems
Next
From: Simon Riggs
Date:
Subject: Re: Commitfest problems