Re: 8.4 release planning - Mailing list pgsql-hackers

On Tuesday 27 January 2009 19:04:49 Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
> >> We have tried the short release cycle before, it was called 8.2. It
> >> fails, remarkably.
> >
> > I think this is a bit of revisionsit history.
>
> JD got the release number wrong, it was 8.3, but otherwise there's no
> revisionism involved:
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00786.php
>

The revisionism was that of "remarkable failure".  That was our shortest 
release cycle in the modern era. And it didn't have the advantage of the 
commitfest process. 

But I think what is important here is to recognize why it didn't work. Once 
again we ended up with large, complex features (HOT, tsearch) that people 
didn't want to wait 14 months to see if they missed the 8.3 release. And yes, 
most of these same arguements were raised then... "full text search is killer 
feature", "whole applications are waiting for in-core full text search", "hot 
will give allow existing customers to use postgres on a whole new 
level", "not fair to push back patches so long when developers followed the 
rules", "sponsors wont want to pay for features they wont see for 
years", "developers dont want to wait so long to see features committed", and 
on and on...  

The more I think about it, the more I feel that where we failed for 8.3 was 
not having a short 8.4 cycle lined up, which would give more freedom to bump 
patches to the next release. 

> The theme that our release cycles are too long is not exactly new,
> of course, eg
> http://archives.postgresql.org/pgsql-hackers/2000-05/msg00574.php
> http://archives.postgresql.org/pgsql-hackers/2001-06/msg00766.php
> http://archives.postgresql.org/pgsql-hackers/2003-11/msg00889.php


Yeah, I remember all that, and I think you'll find that I mostly was on the 
other side of this issue :-)

But many of the arguments from back then don't apply any more. Remember when 
you couldn't depend on pg_dump giving you dumps in the right order? Now that 
was a recipe for painful upgrades. With things like Slony, it's now possible 
to upgrade a majority of the Postgres installations with extremely minimal 
downtime. (And yes, I happen to have one that wont work with slony, but 
hey...)

> but by now I think we've learned to stop banging our heads against
> that particular rock.  One-year major cycles work for this project,
> shorter ones are wishful thinking.
>

Do they? 1 year cycles certainly don't solve the problem of being left with 
big/complex left over patches. They don't decrease the amount of time (as a 
percentage) we spend in freeze/beta/release mode. And we don't even get them 
out in 1 year; this 1 year cycle looks like at least 15 months. 

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