Re: Feature freeze progress report

Stefan Kaltenbrunner wrote:
> Simon Riggs wrote:
> > 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'm not really convinced that this is good idea at all - it would lead

Agreed, a bad idea.

> > 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 would rather like to see patches we don't are confident enough in to
> be dropped from 8.3 and moved to 8.4 - the goal should not be jamming as
> much patches into a single release s we can (because they are proposed)
> but rather putting those in that meet the quality bar and we trust in.

I don't want us postponing patches for a later release if the patch will
be no easier to apply later than it is right now, i.e. if it is "buckle
down" now or "buckle down" later, we might as well do it now, hence my
desire to move things along now rather than when our backs are against
the wall to get a release out.

Of course, patches were will learn more by waiting for 8.4 should
probably be kept for that release.

> again - the bottleneck right now seems to be reviewer capacity coupled
> with a large number of intrusive patches. So the most logical answer is
> to drop those patches we are not fully confident in and try to get them
> in during 8.4.

We are not going to magically have more time or be more confident for
8.4. If a patch needs more research or time, we should hold it, but not
having time to review it isn't a reason to hold it -- it just
bottlenecks the next release.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +