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