Re: Commitfest problems - Mailing list pgsql-hackers

On 16/12/14 13:44, David Fetter wrote:

> On Tue, Dec 16, 2014 at 11:09:34AM +0000, Mark Cave-Ayland wrote:
>> On 16/12/14 07:33, David Rowley wrote:
>>
>>> On 16 December 2014 at 18:18, Josh Berkus <josh@agliodbs.com
>>> <mailto:josh@agliodbs.com>> wrote:
>>>
>>>     > Man. You're equating stuff that's not the same. You didn't get your way
>>>     > (and I'm tentatively on your side onthat one) and take that to imply
>>>     > that we don't want more reviewers.
>>>
>>>     During that thread a couple people said that novice reviewers added no
>>>     value to the review process, and nobody argued with them then.  I've
>>>     also been told this to my face at pgCon, and when I've tried organizing
>>>     patch review events.  I got the message, which is why I stopped trying
>>>     to get new reviewers.
>>>
>>>     And frankly: if we're opposed to giving credit to patch reviewers, we're
>>>     opposed to having them.
>>>
>>>
>>>
>>> I'd just like to add something which might be flying below the radar of
>>> more senior people. There are people out there  (ike me)  working on
>>> PostgreSQL more for the challenge and perhaps the love of the product,
>>> who make absolutely zero money out of it. For these people getting
>>> credit where it's due is very important. I'm pretty happy with this at
>>> the moment and I can't imagine any situation where not crediting
>>> reviewers would be beneficial to anyone.
>>
>> This is exactly where I am at the moment, having previously been more
>> involved with the development side of PostgreSQL during the past.
>>
>> Personally having a credit as a patch reviewer isn't particularly
>> important to me, since mail archives are good enough these days that if
>> people do query my contributions towards projects then I can point them
>> towards any reasonable search engine.
>>
>> The biggest constraint on my ability to contribute is *time*.
>>
>> Imagine the situation as a reviewer that I am currently on the mailing
>> list for two well-known open source projects and I also have a day job
>> and a home life to contend with.
>>
>> For the spare time that I have for review, one of these projects
>> requires me to download attachment(s), apply them to a git tree
>> (hopefully it still applies), run a complete "make check" regression
>> series, try and analyse a patch which will often reference parts to
>> which I have no understanding, and then write up a coherent email and
>> submit it to the mailing list. Realistically to do all this and provide
>> a review that is going to be of use to a committer is going to take a
>> minimum of 1-2 hours, and even then there's a good chance that I've
>> easily missed obvious bugs in the parts of the system I don't understand
>> well.
>>
>> For the second project, I can skim through my inbox daily picking up
>> specific areas I work on/are interested in, hit reply to add a couple of
>> lines of inline comments to the patch and send feedback to the
>> author/list in just a few minutes.
> 
> With utmost respect, you've missed something really important in the
> second that the first has, and frankly isn't terribly onerous: does an
> actual system produce working code?  In the PostgreSQL case, you can
> stop as soon as you discover that the patch doesn't apply to master or
> that ./configure doesn't work, or that the code doesn't compile:
> elapsed time <= 5 minutes.  Or you can keep moving until you have made
> progress for the time you've allotted.

As per my previous email, it's generally quite rare for a developer to
post non-working code to a list (in some cases someone will send a quick
reply pointing that this needs to be rebased because it appears to
reference an old API). From what I see in PostgreSQL this mostly happens
because of bitrot between the time the patch was posted to the list and
the actual commitfest itself - so in one way the commitfest system
exacerbates this particular problem further.

> But the bigger issue, as others have pointed out, has never been a
> technical one.  It's motivating people whose time is already much in
> demand to spend some of it on reviewing.
> 
> I wasn't discouraged by the preliminary patch review process or any
> feedback I got.  My absence lately has more to do with other demands
> on my time.

I am completely in agreement with you here. My approach is more along
the lines of that I know access to long periods of time to review
patches is often impractical, and so how can the review process be made
more time-efficient in order to allow you, me and other people in
similar time-limited environments to be able to participate more?


ATB,

Mark.