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