Gregory Stark <stark@enterprisedb.com> writes:
> 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.
That doesn't seem particularly appealing for our purposes. What it
sounds like is that all the development happens somewhere outside the
main tree, and every so often everybody tries to land a bunch of large
patches at once. That's going to be a mess if the patches interact at
all, and it certainly isn't going to address my primary concern of
encouraging a publicly-visible development process instead of having
people hiding in a corner until they can drop a large patch on us.
> 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.
Here I agree - partly. With some continuing effort these patches could
be in fine shape to apply by the time we branch CVS for 8.3 development.
However, our traditional approach to beta period is that it's supposed
to be a "quiet time" where people focus on testing, debugging, and
documentation. Shepherding people who are doing major development
during that period is likely to be a serious distraction from making the
release ready and high-quality.
regards, tom lane