Re: Last gasp

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Christopher Browne" <cbbrowne(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Last gasp
Date: 2012-04-10 16:53:23
Message-ID: 4F841F330200002500046D81@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Urbański 2012-04-10 17:07:41 Re: plpython triggers are broken for composite-type columns
Previous Message Tom Lane 2012-04-10 16:44:57 Re: Last gasp