Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > The original plan was that anything not 100% ready to commit at the > beginning of the last commit fest will be bumped to the next release, > and beta would start right after the first commit fest, a week or two > after the submission deadline. We failed to enforce that.
Uh, no, that's historical revisionism, cf http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Development_Plan We expected and scheduled for a longer-than-normal final commitfest. There's two months in the original schedule, whereas expectation was that earlier ones would be less than a month (which mostly they were). What we did say, and didn't enforce, was that patches too large to be reviewed in a reasonably short time would be bounced. We thought we'd be able to make that stick if large patches got reviewed and applied in an incremental fashion over the series of commitfests. For one reason or another that never happened for SEPostgres. We should try to analyze exactly why not, although I think the bottom-line answer there has to do with nobody being particularly eager to work on it. Hot Standby had a different timeline, and quite frankly should have never been seriously considered for 8.4 at all. But I think that as long as SEPostgres was looming on the horizon, we didn't see the point of being strict about deadlines ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers