Re: Commitfest problems

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(at)agliodbs(dot)com
>>> <mailto:josh(at)agliodbs(dot)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.