On Mon, Mar 26, 2012 at 4:36 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Well, wait a minute. There's a difference between half-baked and
> reacting to a review that changes the goal of a patch. My idea of the
> code I wanted to write here is extremely different from what we as a
> community decided to be doing. The main part of the code churn has been
> answering to review, removing features and cleaning the code afterwards.
Sure. And if this weren't the final CommitFest, we would have bumped
this to the next CommitFest two months ago. Since it is the final
CommitFest, we're going to go on and on and on. Already we have
almost as many patches queued up for the next CommitFest as we do
remaining in this one. So my question is: how long should we keep all
those people waiting for the purpose of squeezing more stuff into 9.2?At the beginning of this CommitFest, various
peopleoffered time
frames ranging between 6 weeks to 2 months. We're past that now. If
you don't think that was a long enough time frame, then how long do
you think we should wait? It doesn't seem to me to matter very much
whether this got stretched out due to fundamental design deficiencies
or just because it takes a while to beat a major feature into
committable form; surely it's not a shock that this patch wasn't going
to go in overnight.
> If you want to punt this patch out of 9.2 after all the changes I had to
> make for it to be a candidate for 9.2, I think it would be only fair for
> you to find a show stopper in my current implementation. The trigger
> firing order is about an hour of work, so not a stopper I believe.
I don't think there is a show-stopper. I do think there is probably a
lot more cleaning up, tidying, and adjusting needed.
> And as soon as we're done here, you know I'll put the same hours and
> energy into reviewing other people patches :)
As soon as we're done here, the CommitFest will end, and there won't
be any other people's patches to review.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company