Re: Commitfest problems - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Commitfest problems
Date
Msg-id 15941.1418671170@sss.pgh.pa.us
Whole thread Raw
In response to Re: Commitfest problems  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.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.

Yeah; that would totally destroy the use of git bisect, which was supposed
to be an advantage of smaller patches.

Perhaps you could always design the patch split-up in such a way that
each incremental step still compiles, but that would greatly limit how
you could factorize the patch, so I'm not sure it comes out as a win.
If we're going to submit patches in small chunks I'd rather the chunks
are built around separation of concerns, and not held to "would this
compile in isolation?".

IOW, submission in chunks is one thing but it shouldn't necessarily
translate to committing in the same chunks.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Commitfest problems
Next
From: Andrew Dunstan
Date:
Subject: Re: Commitfest problems