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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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