Skip site navigation (1) Skip section navigation (2)

Re: damage control mode

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: damage control mode
Date: 2010-01-08 17:01:34
Message-ID: 4B47108E020000250002E085@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <bruce(at)momjian(dot)us> wrote:
 
> here is the ideal schedule:
> 
> 	Jan 15 start commitfest
> 	Feb 15 stop commitfest
> 	Apr  1 start beta
> 	Jun  1 release release candidate (RC)
> 	Jun 20 release 8.5
 
> Of course we rarely have an ideal schedule
 
So for a project which strives for an annual release, we have over
six months from initial submission of a *small* patch until the
release it goes in, if we meet the ideal schedule?  Longer for large
patches or if we slip from the ideal schedule?  That sounds like
there are still some opportunities for improvements in project
management, but it's not *so* bad if development for the next
release can overlap the tail end of that schedule.  I'm not sure how
much that is anticipated or encouraged, though.
 
It also seems to call into question the wisdom of annual releases. 
If we had a two-year cycle which had three times as much in it,
would that be an improvement, or not?
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-01-08 17:03:22
Subject: Re: true serializability and predicate locking
Previous:From: Stephen FrostDate: 2010-01-08 16:59:10
Subject: Re: RFC: PostgreSQL Add-On Network

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group