Re: Commitfest II CLosed - Mailing list pgsql-hackers

On Mon, Oct 21, 2013 at 9:18 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-10-21 09:15:36 -0400, Peter Eisentraut wrote:
>> On 10/21/13 1:31 AM, Andres Freund wrote:
>> > The point of the CF is exactly that all
>> > patches get at least one good round of review. Moving unreviewed patches
>> > to the next CF will let them just suffer the same fate there.
>>
>> What is the alternative?
>
> I am not 100% sure, but what's the point of the CF if we're not actually
> reviewing patches that wouldn't get review without it? So I guess it's
> not starting the next one before we've finished - which we obviously
> haven't in this case - the last one.

Yeah.  There were a huge number of patches in this CommitFest that sat
around in the waiting on author state for hugely long periods of time.One of the critical functions of the CommitFest
manager(s)IMV is to
 
make sure that patches that are in that state get pushed to Returned
with Feedback so that it's more obvious which things are still alive
and kicking.  That really wasn't done until about a week before the
end of the CommitFest, when I stepped in and did some of it.  But that
really needs to be more of an ongoing process.

Supposedly, we have a policy that for each patch you submit, you ought
to review a patch.  That right there ought to provide enough reviewers
for all the patches, but clearly it didn't.  And I'm pretty sure that
some people (like me) looked at a lot MORE patches than they
themselves submitted.  I think auditing who is not contributing in
that area and finding tactful ways to encourage them to contribute
would be a very useful service to the project.

Finally, I think we need to have some discussion of the patches that
are ready for committer but got punted, and see if we can figure out
whether any committer has plans to look at them.  Those patches are:

Extension Templates - I think Peter Eisentraut commented on this one
at some stage, but I'm not sure if he's planning to work further on
it.
UNNEST with multiple args, and TABLE with multiple functions - Heikki
did some work on this, maybe he's planning to commit it?
Numeric Aggregates Performance Improvement - I looked at this one
previously so should probably look it over again.
Statistics collection for CLUSTER command - Noah recommended rejecting
this on performance grounds.  Maybe we should do that.
simple date time constructors - Alvaro previously looked at this, but
I don't know whether he plans to work on it further.
simple LO API - no committer interest to my knowledge
Bugfix for timeout in LDAP connection parameter resolution - I think
Peter Eisentraut is planning to commit this

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company