Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)

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