Re: 8.4 release planning - Mailing list pgsql-hackers

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