Re: Last gasp - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Last gasp
Date
Msg-id 4F841F330200002500046D81@gw.wicourts.gov
Whole thread Raw
In response to Re: Last gasp  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Last gasp  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> One other sort of mechanical test which I think can and should be
>> applied to patches submitted to the last CF is that if *at the
>> start of the CF* the patch doesn't apply, compile, pass
>> regression tests, and demonstrably provide the functionality
>> claimed for the patch, it should not be a candidate for inclusion
>> in the release.
> 
> I would not be in favor of inflexible application of such a rule.
> For instance, if a patch had gotten broken by a conflict with some
> other patch applied the day before the CF starts, it would be
> unfair to not give the patch author a reasonable amount of time to
> rebase.  And such conflicts occurring after the CF starts are
> hardly unusual either.
I didn't mean to exclude rebasing because of conflicts with recent
commits, so perhaps "mechanical" was overstating it.  But maybe not
-- perhaps each patch submission should state which commit it was
last confirmed to compile and work with, and if there are problems
against HEAD that could be confirmed before asking for the rebase. 
That wouldn't be too much extra work for the initial reviewer, and
it would help establish objective criteria for categorizing whether
a patch should be treated as WIP.
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Last gasp
Next
From: Jan Urbański
Date:
Subject: Re: plpython triggers are broken for composite-type columns