Re: 2018-03 Commitfest Summary (Andres #1) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: 2018-03 Commitfest Summary (Andres #1)
Date
Msg-id 20180302194808.voc76uclxf7uupcf@alap3.anarazel.de
Whole thread Raw
In response to Re: 2018-03 Commitfest Summary (Andres #1)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: 2018-03 Commitfest Summary (Andres #1)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: 2018-03 Commitfest Summary (Andres #1)  ("Tels" <nospam-pg-abuse@bloodgate.com>)
List pgsql-hackers
Hi,

On 2018-03-02 11:06:12 +0100, Fabien COELHO wrote:
> A lot of patches do not even get a review: no immediate interest or more
> often no ressources currently available, patch stays put, I'm fine with
> that.

Well, even if that's the case that's not free of cost to transport them
from fest to fest. Going through them continually isn't free. At some
point we just gotta decide it's an undesirable feature.


> Now, some happy patches actually get reviews and are switched to ready,
> which shows that somebody saw enough interest in them to spend some time to
> improve them.
> 
> If committers ditch these reviewed patches on weak ground (eg "I do not need
> this feature so nobody should need it"), it is both in contradiction with
> the fact that someone took the time to review it, and is highly demotivating
> for people who do participate to the reviewing process and contribute to
> hopefully improve these patches, because the reviewing time just goes to the
> drain in the end even when the patch is okay.

The consequence of this appears to be that we should integrate
everything that anybody decided worthy enough to review. That just
doesn't make sense, we can't maintain the project that way, nor will the
design be even remotely coherent.

Sure it's a balancing act, but nobody denies that.


> So for me killing ready patches in the end of the process and on weak ground
> can only make the process worse. The project is shooting itself in the foot,
> and you cannot complain later that there is not enough reviewers.

How would you want it to work otherwise? Merge everything that somebody
found review worthy? Have everything immediately reviewed by committers?
Neither of those seem realistic.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Early locking option to parallel backup
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] pgbench randomness initialization