Re: Large Commitfest items - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Large Commitfest items
Date
Msg-id CAMsr+YGeWm_tBU8PgywscBJPrLWd2u79mX2=caUXgWjmuFdOLQ@mail.gmail.com
Whole thread Raw
In response to Re: Large Commitfest items  (Andres Freund <andres@anarazel.de>)
Responses Re: Large Commitfest items
List pgsql-hackers
On 2 July 2018 at 02:50, Andres Freund <andres@anarazel.de> wrote:
Hi,

On 2018-07-01 14:46:47 -0400, Andrew Dunstan wrote:
> There has been some discussion around excluding large items from the
> current commitfest, for several reasons. However I don't recall ever
> seeing a definition of a large item. It seems to be a bit like "I know
> it when I see it."   I've been looking at the current commitfest
> entries. Based on that I suggest a heuristic that says a commitfest
> item with patches greater than 5000 lines is large.

FWIW, I personally think the criteria should rather be "old" or "very
small". I.e. for patches that have waited for review being large
shouldn't necessarily be an impediment for getting worked on (depending
on invasiveness maybe not committed), and very small for newer things
should be way below 5kloc.


I agree. I think the idea is to stop people (um, totally not guilty of this) from dropping big or intrusive patches in late CFs. 

A 10 line patch can be massively intrusive and contentious. A 5000 line patch can be a mechanical change that nobody disagrees with, or a mature patch that just needed a few tweaks and missed commit in the last CF.

If a line limit is used, we'll get people optimising for the line limit. I don't think that's a win.

This benefits from being fuzzy IMO.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Synchronous replay take III
Next
From: Peter Geoghegan
Date:
Subject: Re: Bulk Insert into PostgreSQL