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
|
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: