DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=A1DSeO3qGJgZyV+MJJb3TmwLtd7i7GGmO7i6umne/j0fVk0ETN/T1tW5fzawTb9h8hREKPzJMX9bqShdB4vU3rIdmL//56YmsjErd8GVAfOtCaJSsGWELM6V348mN0toiS8cnDuUb1j7pBPbk09oZDttViLITVDUrhjQrma+PMs=
Message-ID: <46349EF4.2010304@enterprisedb.com>
Date: Sun, 29 Apr 2007 14:34:44 +0100
From: Heikki Linnakangas <heikki@enterprisedb.com>
User-Agent: Icedove 1.5.0.10 (X11/20070329)
MIME-Version: 1.0
To: Simon Riggs <simon@2ndquadrant.com>
CC: Bruce Momjian <bruce@momjian.us>,
	PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: Feature freeze progress report
References: <200704270313.l3R3DwF16449@momjian.us>
	<1177792836.3663.61.camel@silverbirch.site>
In-Reply-To: <1177792836.3663.61.camel@silverbirch.site>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Simon Riggs wrote:
> My thinking is to move to a two stage release process: Do one
> "production" release annually, and one "dev" release at the 6 month
> mid-point. That way each new release contains a manageable number of new
> features and we have a realistic chance of integrating them
> successfully. Support companies would then have the option to support
> both releases, or just the main production release. Leading edge users,
> of which we have many, would then benefit from more frequent additional
> features.

I like the idea of draining the patch queue mid-way through the release 
cycle. That'll hopefully encourage people to submit patches earlier in 
the release cycle, knowing they will be reviewed. It'll also give people 
working on external projects, drivers and tools, a checkpoint to sync with.

But I don't like the idea of making a release out of it. Who would use 
such a release? No one in production. Making a release comes with a 
cost, even if it's just a dev release.

One could also argue that we don't need the mid-cycle checkpoint, if we 
just keep the patch queue empty all the time. In the end, it comes down 
to how many people we have actively reviewing patches and giving 
feedback (I agree that it's not a linear relationship as you pointed out 
later in your mail, though). I believe a mid-cycle checkpoint would help 
by directing efforts to review, just like the pre-release feature freeze 
does.

> I would also suggest that 8.3 be labelled a dev release. We have a
> reasonable number of fairly invasive patches, so we need a mechanism to
> integrate them with reduced risk.

I have no reason to believe that the next release will have less patches 
in it, so if we went down that path we could never release a stable 
release. If we have reasonable doubts about the stability of a patch, it 
should not be included. That said, all patches come with a risk.

> With those two suggestions, the prod release would freeze on Sep 30 and
> the dev release on Mar 31. This would then put us into the same
> situation as Linux, where odd-numbered releases are dev and
> even-numbered are main releases. Everyone would understand our decision
> to take this action, as well as immediately understanding how this
> process will work in the future.

We're having a short 8.3 cycle because we wanted to shift our release 
schedule from Autumn to Spring. That would get us back to releasing in 
Autumn.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com