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
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 |