Tom Lane <tgl@sss.pgh.pa.us> 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