Re: Last gasp - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Last gasp
Date
Msg-id CA+TgmoY3QkiSTTPige7g+sEr-Ea1NKvq9baCo-+FF_rAiS7snA@mail.gmail.com
Whole thread Raw
In response to Re: Last gasp  (Andres Freund <andres@anarazel.de>)
Responses Re: Last gasp  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Tue, Apr 10, 2012 at 9:32 PM, Andres Freund <andres@anarazel.de> wrote:
> They might have been half-baked. But several of those didn't get design-level
> review for several weeks which makes it rather hard to fully bake them in
> time...

Yeah, I noticed.  People other than committers can do design reviews,
of course, and historically have, just not so much this time (though
Noah, for example, did excellent reviews of everything he looked at).
And people can post a design and ask for feedback before starting to
code.  In fact, once upon a time, it was understood to be recommended
practice.

I think that Alvaro got a little bit of a bum steer in this area: his
patch was big and complicated, he posted design stuff well in advance,
including both many emails to hackers and multiple blog articles, and
he got very little review from anyone.  I personally would have liked
to spend more time on that, but I simply did not have time.  More
people reviewing would have helped with that.  Making Alvaro a
committer wouldn't, because he already is.

I also think that the array foreign key thing didn't get reviewed
until awfully late.  But on the flip side, when it did get reviewed,
it was Noah who did it, not a committer, and all signs suggest he did
quite a good job pushing the patch toward a sensible design, as well
as cleaning up implementation problems.  Admittedly, if Noah were a
committer, the patch would likely be committed now, but I am not
entirely prepared to second-guess Tom's decision about whether it
should go into 9.2.

The real problem with the command triggers patch is that we got a
blizzard of code.  It's unrealistic to expect anyone to devote serious
review time to a patch that's under constant development.  It also
strikes me that a tremendous amount of pain could have been avoided by
posting a clear and detailed design sketch for that patch before
beginning to code.  Dimitri contended that without code, no one will
read design sketches, but that doesn't for the most part jive with my
experience, and I think that the strategy he actually chose backfired,
because it was clear that any review would be hitting a moving target.

Page checksums didn't really follow the design-before-code rule
either, but in spite of that it got no shortage of attention: Heikki,
Noah, and I all spent significant time on it.

pgsql_fdw provoked a lot of discussion involving many people.  I am
not sure we really know what the right design is there, but it's not
because nobody offered an opinion.  Had I the time I would have thrown
my opinion on the pile, but I'm not sure that would have saved it.  I
have a feeling this might be a big patch with a small patch struggling
to get out of it.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Last gasp
Next
From: Bruce Momjian
Date:
Subject: Re: Uppercase tab completion keywords in psql?