Re: Commitfest problems

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Commitfest problems
Date: 2014-12-15 19:08:21
Message-ID: CA+TgmoZ1mNkAzWo_o2=kWs6nxq8vm4WNy8PFoPHi_PbnVHfssA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland
<mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> wrote:
> However if it were posted as part of patchset with a subject of "[PATCH]
> gram.y: add EXCLUDED pseudo-alias to bison grammar" then this may pique
> my interest enough to review the changes to the grammar rules, with the
> barrier for entry reduced to understanding just the PostgreSQL-specific
> parts.

Meh. Such a patch couldn't possibly compile or work without modifying
other parts of the tree. And I'm emphatically opposed to splitting a
commit that would have taken the tree from one working state to
another working state into a series of patches that would have taken
it from a working state through various non-working states and
eventually another working state. Furthermore, if you really want to
review that specific part of the patch, just look for what changed in
gram.y, perhaps by applying the patch and doing git diff
src/backend/parser/gram.y. This is really not hard.

I certainly agree that there are cases where patch authors could and
should put more work into decomposing large patches into bite-sized
chunks. But I don't think that's always possible, and I don't think
that, for example, applying BRIN in N separate pieces would have been
a step forward. It's one feature, not many.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-12-15 19:19:30 Re: Commitfest problems
Previous Message Jeff Janes 2014-12-15 18:55:30 Re: pgbench -f and vacuum