Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
