Re: Large Commitfest items

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Large Commitfest items
Date: 2018-07-02 01:36:02
Message-ID: CAMsr+YGeWm_tBU8PgywscBJPrLWd2u79mX2=caUXgWjmuFdOLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2 July 2018 at 02:50, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-07-02 01:39:08 Re: Bulk Insert into PostgreSQL
Previous Message Thomas Munro 2018-07-02 00:39:00 Re: Synchronous replay take III