Heikki Linnakangas wrote:
> 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.

Aside from a few complex patches all the patches in the queue are from
work completed just before feature freeze --- we have been draining it
during the entire release.  I think for the few complex patches that
have been in there for a while, the problem is that reviewing them is
going to be so hard, no one has done it.  Now that we are in feature
freeze, we have to do it --- but the idea that we have somehow just been
holding patches during the whole release isn't true.

  Bruce Momjian  <[EMAIL PROTECTED]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to