Re: 8.4 release planning

All,

So, some feedback to make this decision more difficult:

Users: care about HS more than anything else in the world. I'm
convinced that if we took a staw poll, 80% of our users would be in
favor of waiting for HS. This one feature will make more of a
difference in the number of PG users than any feature since the Windows
port. Maybe more.

on the other hand:

We held back version 4 months 7.4 for Windows, before it became apparent
that there was at least a year more work to do. That was a mistake, and
in many ways HS seems like a similar case.

SE-Linux: this patch has effectively been in development for 2 years
ourside the core process before putting it in; the forked SEPostgres is
in use in production. KaiGai has been available for 20 hours a week (or
more) to troubleshoot issues and change APIs. I really don't see what
the problem is with committing it.

pg_upgrade hasn't recieved a lot of testing because 8.4 has been such a
moving target. I've been waiting for it to settle down so that we can
see if upgrade works. It was always true that pg_upgrade would be among
the last patches tested; we discussed this at pgCon.

==============

Regarding the Commitfests in general: we still haven't perfected this
process. There are a number of issues with it which are hampered by
technology, but a lot more by people. Here's my analysis of what's
changed over the last year:

1) having the last CF on Nov. 1 was a mistake. That put us square in
the path of the US & Christian holidays during the critical integration
phase .. which means we haven't really had 3 months of integration,
we've had *two*.

2) Having the CFs improves visibility. However, as SEPostgres shows, it
doesn't eliminate the ability of major committers to put off dealing
with large complex patches which junior reviewers can't be assigned to.
Particularly if a major reviewer "claims" a patch, but then doesn't
seem to do a lot of review.

3) I don't feel like I got a real handle on the "Round Robin Reviewers"
and got them processing small patches efficiently until the November
review. It just took several cycles to work out how to do it,
particularly given my job change this year.

Better technology would also help, such as automated tracking of patch
changes and when the last time a reviewer spoke up was. Currently, Dave
and I have been doing these things by hand and I know we missed a lot of
patches which stalled. But the main issue is (and will remain) people
and procrastination.

--Josh