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

Re: damage control mode

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: damage control mode
Date: 2010-01-09 21:32:29
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Sat, Jan 9, 2010 at 4:01 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On lör, 2010-01-09 at 14:12 -0500, Robert Haas wrote:
>> If we accept large patches at the very end of the development cycle,
>> that's when people will submit them.  You've previously criticized the
>> high proportion of the release cycle that is set aside for CommitFest
>> and beta, so I'm surprised to see you advocating for a policy that
>> seems likely to lengthen the time for which the tree is closed.
> Just to clarify: I am for sticking to the agreed dates.  If some things
> are not ready by the necessary date plus/minus one, they won't make the
> release.  If it's obvious earlier that something won't make the date, it
> shouldn't be committed, and maybe put on the backburner right now.  But
> AFAICT, that's independent of when it was submitted.  Some things that
> were submitted just the other day might be almost ready, some things
> that were first submitted many months ago are still not ready.

The portion of the schedule I'm worried about is the one where we go
to beta by March 7th.

I think we can get all the remaining large patches committed by
February 15th if Tom doesn't start working on the remaining open items
until February 15th - but then I do not think that we will have a beta
on March 7th.


In response to


pgsql-hackers by date

Next:From: Tim BunceDate: 2010-01-09 21:40:22
Subject: Re: Feature patch 1 for plperl [PATCH]
Previous:From: Tim BunceDate: 2010-01-09 21:27:03
Subject: Re: Initial refactoring of plperl.c - updated

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