Excerpts from Tom Lane's message of mar abr 19 03:34:34 -0300 2011:
> As Robert noted, the purpose of the commitfest mechanism is mostly to
> ensure that patches that *are* committable, or close to it, don't fall
> through the cracks. I'm not sure we're doing anybody any favors by
> trying to shoehorn reviews of WIP ideas into that same process. At the
> very least it seems we'd need a different set of review guidelines for
> WIP items, and we don't have one.
I think this is historical revisionism. Commitfests were mostly created
because of pressure due to the lateness of the HOT patch. Probably
there were other factors too but this is likely the single most
important reason. (I think the term "commitfest" was coined later, but
I don't think this invalidates my point.)
And the way we considered things at the time is that we had failed to
timely review the concepts in the WIP HOT patch that was presented. So
we wanted to ensure that we provided good feedback to WIP patches (to
all patches really) to avoid this failure from repeating. All patches
*and WIP ideas* were supposed to be reviewed by someone, and if they
were to be rejected, some rationale was to be provided.
Somewhere down the line this seems to have been forgotten and we are now
using commitfests just to track finished patches.
So if we want to stick to the original principles we should have some
sort of "different set of review guidelines". Or perhaps we could just
decide that we don't care much about this problem and toss it aside.
Maybe this is something to discuss at the next developer's meeting.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support