Re: Feature freeze progress report - Mailing list pgsql-hackers

On Thu, 2007-04-26 at 23:13 -0400, Bruce Momjian wrote:

> Our community could probably handle a few of these complex patches, but
> the volume for this release is significantly higher than previous
> releases.  The community is doing a good job of giving patch writers
> feedback and new patch versions are getting generated.  However, this
> amount of patch churn is not normal.

I think it is probably going to be normal from now on. We now a
significant number of reasonably prolific developers.

> I think the community has to come up with ideas on how to accomplish this.

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 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.

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.

By agreeing this now, we can then punt a reasonable number of patches
back to the main release, later this year. The de-selected patches still
have a second chance of making it into a release available in 2007 and
this will diffuse the various tensions and difficulties we now have.

Without this, we face a long wait. 8.2 took 4 months to go through beta
and release, so 8.3 could well take 6 months. If we allow 8.3 to be a
mega-release then it might take much longer than that: increases in
complexity have a non-linear effect on software quality/robustness.
Adding reviewers or committers isn't going to dramatically change that.
IMHO the only sensible thing to do is to make releases more frequent so
that each one is still a manageable size. 

The alternative is to somehow select patches to wait until the next
release, a full year away. That is unlikely to be an easy process and
nobody really wants to volunteer their own or others' patches.

Realistically, people won't speed up the frequency they upgrade their
software and we certainly don't want to increase the number of
production releases in circulation that we must support. This set of
proposals is a realistic way forward from where we are and will be
easily explained to people only briefly in touch with our project.

Whether or not this is accepted, I'm happy to offer assistance wherever
the core team directs to improve the current situation.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com