On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote: > Particularly with regard to hot standby, which by any sane reading was > not close to being committable on 1 November (a fortiori from the fact > that it's *still* not committable despite large amounts of later > work).
I've wasted much time in two main areas in recent months: The first area I've wasted time on is patch review. Had I known that some patches on the queue would not be properly reviewed and that time was going to be a factor then I would not have wasted a single second on patch review. My main review item has been Sync Replication, which I did because of Core's statement that we would include that feature in this release. It would appear that my time on that has been both pointless and damaging to my own situation. The second is in developing an answer to the FATAL errors problem, which I asked a direct question on and received a very specific answer: http://archives.postgresql.org/pgsql-hackers/2008-09/msg01809.php I spent two weeks working out a difficult solution to that, a week subsequently arguing with Heikki (possibly longer) about whether it was necessary and then two weeks refactoring it back out again when you were silent. >From my side, I've spent time and money supporting your views and decisions, without argument with you, though most would not see that. I learned on Jan 12 that you'd been too busy to consider this work and that a priori you argued for patch rejection. It would be much simpler if I had badly screwed up or if we'd found an awkward showstopper. That hasn't happened. In fact, I've done the full dance so far. I fail to see how rejecting unreviewed patches provides benefit for users, developers or sponsors. How does de-committing from features voted most-popular or promised by core sit with users? How will developers react when they know that helping in patch review assists their own demise? How will sponsors react when they see another set of patches rejected? If there is a problem with timing it's because we need more planning, scheduling and prioritisation of resources. But it isn't possible to do it retrospectively without causing problems, and those problems may be worse than slipping a month, or three. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
