pg.ddx.io pgsql-hackers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Noah Misch <noah@leadboat.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Christopher Browne <cbbrowne@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Last gasp
Date: Tue, 10 Apr 2012 20:12:38 -0400
Message-ID: <20120411001238.GA12529@tornado.leadboat.com> (raw)
In-Reply-To: <4F841F330200002500046D81@gw.wicourts.gov>
References: <CAAZKuFbHQA6Q3hO5amMLh6Zvh=-8tdKeQFUacdDVREnvp889Jg@mail.gmail.com>
<4F7E99BA.1080805@2ndQuadrant.com>
<CA+TgmoaRRSyLQ4qaW82aLQ1bM40oJ-eZc0mWXsBF2__xjH4xzA@mail.gmail.com>
<20120409053852.GG11987@tornado.leadboat.com>
<CA+TgmoZphWOJdF7AjBGs1Awf6QM3Gb0e+kvZe4+8-uyBTgSsJg@mail.gmail.com>
<20120409222359.GE30702@tornado.leadboat.com>
<CA+TgmobrGWaatFbuMGJKL4J2AcJCaw3hF-37r8xmxHg7v98smw@mail.gmail.com>
<CAFNqd5V274gzVEAX7q=nwGn3eTsPa+B_E_WkQ8oPu1ZEYxa1eg@mail.gmail.com>
<10796.1334075758@sss.pgh.pa.us>
<4F841F330200002500046D81@gw.wicourts.gov>
On Tue, Apr 10, 2012 at 11:53:23AM -0500, Kevin Grittner wrote:
> 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.
Of the patches I've reviewed that fall into one the problem categories Robert
outlined, all applied cleanly and passed regression tests. On the flip side,
I have submitted at least two patches that failed regression tests for the
reviewer due to isolated, easily-fixed blunders. Consequently, I'm not
hopeful about these checks as coarse indicators of patch readiness. I would
certainly like an objective test for assigning patches to those categories,
but I don't have a better idea for such a test.
nm
view thread (161+ messages) latest in thread
Message-ID: <20120411001238.GA12529@tornado.leadboat.com> Permalink: ../20120411001238.GA12529@tornado.leadboat.com/ Also on: postgresql.org/message-id/20120411001238.GA12529@tornado.leadboat.com ·
reply
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Reply to all the recipients using the --to and --cc options: reply via email To: pgsql-hackers@postgresql.org Cc: noah@leadboat.com, Kevin.Grittner@wicourts.gov, tgl@sss.pgh.pa.us, cbbrowne@gmail.com, robertmhaas@gmail.com Subject: Re: Last gasp In-Reply-To: <20120411001238.GA12529@tornado.leadboat.com> * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox