public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Simon Riggs <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Feature freeze progress report
Date: Sun, 29 Apr 2007 14:34:44 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
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
view thread (98+ 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]
Subject: Re: Feature freeze progress report
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