"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.
> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
