Re: 8.4 release planning - Mailing list pgsql-hackers

From Robert Treat
Subject Re: 8.4 release planning
Date
Msg-id 200901271649.31481.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: 8.4 release planning  (dpage@pgadmin.org)
Responses Re: 8.4 release planning  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Monday 26 January 2009 15:13:56 dpage@pgadmin.org wrote:
> On 1/26/09, Josh Berkus <josh@agliodbs.com> wrote:
> > All,
> >
> >>> 1) having the last CF on Nov. 1 was a mistake.  That put us square in
> >>> the path of the US & Christian holidays during the critical integration
> >>> phase ..
> >>> which means we haven't really had 3 months of integration, we've had
> >>> *two*.
> >
> > Actually, I'm thinking about this again, and made a mistake about the
> > mistake.  The *original plan* was that we were not going to accept any
> > new patches for Nov-CF.  Just revised patches from eariler Fests.  We
> > didn't stick to that, which is mostly why we are still reviewing now.
>
> I don't recall us discussing that, but it sounds like it might help next
> cycle.
>

What would be the significance of opening up the tree to future development 
between the last commitfest and last commitfest -1, if no new patches could 
be introduced?

Essentially this is where we are at now... November commit fest finished, 
December we "re-opened" for development, and we're in the January commitfest 
where no new features have been accepted.  

The problem is what to do when we get to the end of the commit fests, and we 
have a few reamining (invariably large/complex) patches that people don't 
want to push. 

I had been leaning toward the idea of pushing the 8.4 release back six months, 
but reopening development for 2-3 more development/commitfest cycles, but I 
am starting to think this is moving things in the wrong direction. 

Now I am starting to think that we cannot prevent large patches from showing 
up at the end of a cycle no matter what, and the only way to really "solve" 
that problem is to lesson the pain of getting bumped from a release. Ie. 
instead of being bump meaning you must wait 12-14 months till next release, 
we move toward more of a 6 month cycle of development.  I'm not sure it's 
feasible to boil down beta/rc phase to two months, tough it seems possible if 
we were strict about bumping features that aren't ready, and if our 
development cycles only went 4 months.  For end users who are concerned about 
continuous upgrading, we might think about putting restrictions on every 
other release (ie. require binary or data file level compatability with 8.4 
for the 8.5 release, and remove that restriction for 8.6) to lesson the 
upgrade path. (alternativly, a working IPU plan could make that less of an 
issue)

-- 
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com


pgsql-hackers by date:

Previous
From: Ron Mayer
Date:
Subject: Re: 8.4 release planning
Next
From: Magnus Hagander
Date:
Subject: Re: Commitfest infrastructure (was Re: 8.4 release planning)