Christopher Browne <cbbro...@gmail.com> wrote: > Robert Haas <robertmh...@gmail.com> wrote: >> CommitFests are a time for patches that are done or very nearly >> done to get committed, and a time for other patches to get >> reviewed if they haven't been already. If we make it clear that >> the purpose of the CommitFest is to assess whether the patch is >> committable, rather than to provide an open-ended window for it >> to become committable, we might do better. > > Yeah, I think there's pretty good room for a "+1" on that. Yeah, +1 for sure. 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. 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." <onlyhalfkidding>Perhaps we should have a concept of "feature months" -- so that when we look at holding up a release with 20 features for two months so that one more feature can make it in, the cost side of the equation is 40 feature-months, and the benefit is 10 feature-months. (Remember, you can't count the added feature as though it's there for a year before the next release if it holds the release up.)</onlyhalfkidding> -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
