Tom Lane <[EMAIL PROTECTED]> writes: >> If you look at the two "incomplete" patches, and the "misfired" one >> (Bitmaps, Updatable Views, and WITH RECURSIVE) all of them are patches >> where the submitter had been working on them months ago, and might have >> made the release (or let us know they weren't on schedule) if we'd held >> them to an earlier deadline. > > Perhaps, but I'm not sure what we can or should do about it. Moving > deadlines up will either create a dead zone where we all sit around > twiddling our thumbs, or people will keep on coding till the last minute > anyway.
I don't think that's what would happen at all. In fact what I think would happen is that it would free up people like you to work on stuff you're interested in instead of reviewing patches. As an extreme example consider the new Linux release cycle. They have a non-freeze period of a couple weeks, followed by months of frozen time. Users who want to try out new features on different hardware can do so and often turn up problems developers reviewing the patches missed. Developers spend the months of frozen time working on new patches which, if they're ready on time, all go into the queue in the first few weeks of a new release. If they miss the window they'll make the next one. As a result they don't get things like what we saw with 8.0 where major new features like PITR, nested transactions and so on all hit the tree in the final days before the freeze. Instead they go in early and if they turn out to be immature they get pulled long before the actual release. I would love to see the bitmap indexes and updatable views get merged into the tree just weeks after the release comes out rather than disappear again until just before the next release. If I were a user depending on these new features it would give me a hell of a lot more confidence if people could say they've been in the CVS version for months and nobody's had problems with them than to be told they were reviewed by one person three weeks ago and nobody else has had much of a chance to use it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
