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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers