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




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to