CommitFest 2011-01 as of 2011-02-04

Here's where I think we are with this CommitFest.

We have committed 45 patches and returned with feedback or rejected
23.  There are 30 remaining patches, every single one of which has
been reviewed.  20 of those are marked Ready for Committer; 5 are
marked Waiting on Author; 5 are marked Needs Review.  However, again,
even the ones that are marked as Needs Review have in fact been
reviewed multiple times, in many cases by multiple people.  Thanks to
all who have contributed to the reviewing effort, especially Stephen
Frost, Hitoshi Hirada, Alex Hunsaker, Noah Misch, and Itagaki
Takahiro.

I respectfully submit that every patch which is not yet Ready for
Committer is in that state not because of any neglect on the part of
anyone in the community, but because it's got problems.  It isn't
done; it turned out to be more complicated than anticipated; it wasn't
updated in a timely fashion; and/or we had difficulty reaching
agreement on the best way forward (and still haven't).  Most of these
patches should probably be deferred to 9.2.

So there are two basic difficulties with wrapping the CommitFest up.
One is that the 20 patches which are marked Ready for Committer really
deserve to be looked at by a committer, and hopefully committed.
Unfortunately, my ability to help in this area will be somewhat
limited, because at least half of the remaining patches are in areas
that I know nothing about (e.g. 7 PL/python patches).

The second problem is that the patches that are in serious trouble
including synchronous replication and SQL/MED, which are key features
I know we're all hoping to have for 9.2.   However, we have to face
the fact that getting these features in may involve quite a bit of
delay.  With respect to SQL/MED, Heikki tells me that he is working on
the core patch, and I am hopeful that will be committed soon.
However, file_fdw is in pretty serious trouble because (1) the copy
API patch that it depends on still isn't committed and (2) it's going
to be utterly broken if we don't do something about the
client_encoding vs. file_encoding problem; there was a patch to do
that in this CF, but we gave up on it.  And postgresql_fdw was hacked
up by Heikki but he didn't seem to have much confidence in it and no
one else has reviewed his hacked-up version.  With respect to
synchronous replication, Dan Farina and I have extracted some of the
less-intrusive bits of that patch.  One of those changes (standby
replies) is committed, though it seems to need a bit of fixup, and the
other two are awaiting review.  Simon also reported that he is working
on this, but I'm not certain of the specifics.  Based on the looking
at that patch that I did so far, it certainly needs cleanup, and there
may be some more serious architectural issues that need to be
addressed also.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company