public inbox for [email protected]  
help / color / mirror / Atom feed
From: Tom Lane <[email protected]>
To: Gregory Stark <[email protected]>
Cc: [email protected]
Cc: Bruce Momjian <[email protected]>
Cc: [email protected]
Subject: Re: Getting a move on for 8.2 beta
Date: Fri, 01 Sep 2006 21:37:58 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Gregory Stark <[email protected]> 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



view thread (101+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Getting a move on for 8.2 beta
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox