Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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