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

From Fabien COELHO
Subject Re: 2018-03 Commitfest Summary (Andres #1)
Date
Msg-id alpine.DEB.2.20.1803021050160.12500@lancre
Whole thread Raw
In response to Re: 2018-03 Commitfest Summary (Andres #1)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 2018-03 Commitfest Summary (Andres #1)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hello Tom,

> FWIW, I share Andres' concern that pgbench is being extended far past 
> what anyone has shown a need for.  If we had infinite resources this 
> wouldn't be a big problem, but it's eating into limited committer hours 
> and I'm not really convinced that we're getting adequate return.

Another specific point about the CF patch management:

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.

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.

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.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: 2018-03 Commitfest Summary (Andres #3)
Next
From: Kuntal Ghosh
Date:
Subject: Re: zheap: a new storage format for PostgreSQL