Re: Last gasp

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Cc: "Christopher Browne" <cbbrowne@gmail.com>, "Robert Haas" <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-04-10T16:35:58Z
Lists: pgsql-hackers
"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.

> A patch on
> which the author is continuing to work even in the absence of review
> should be considered a WIP "want feedback" submission; it should not
> be allowed to constitute a "placeholder" for inclusion in the
> release.  It's one thing if review turns up corner case bugs missed
> by the author; it's quite another if there is a month or two of
> solid development left to be done. The CF period is not the time for
> "now I'll get serious about wrapping this up."

Agreed here, though.  Chris Browne mentioned upthread that we really
need a somewhat different process for WIP patches as opposed to those
that are thought to be committable or nearly so.  I don't know if we
should institute his idea of a separate series of "HackFest" events,
but at the very least we should try harder to draw a distinction between
WIP and finished patches.  They need different sorts of reviewing.

			regards, tom lane