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

Re: damage control mode

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, David Fetter <david(at)fetter(dot)org>
Subject: Re: damage control mode
Date: 2010-01-10 06:28:46
Message-ID: 201001100128.46974.xzilla@users.sourceforge.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Saturday 09 January 2010 16:32:29 Robert Haas wrote:
> 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.
>
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01251.php
>
> 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.
>

1) The goal of any CF should not be that everything submitted gets committed, 
but that everything gets reviewed.

2) ISTM what had the most agreement was that the large/ugly patches that show 
up late should have no expectation of being committed (though we will try to 
review them), and also that they would be first in line for being punted should 
we start missing dates.

3) Our biggist problem wrt oscillating between a time based and feature based 
release has not been releasing the software, but on never even settling on a 
feature set to get into beta with. 

Given that, if we follow the normal CF process, by Feb 15 we should have a 
clear indication of what is and is not ready for commit, and my suspicion is 
that those large patches you are most worried about will have taken care of 
themselves (one way or the other)

But I don't see much sense in worrying about it now; the 2 weeks between end 
of CF and Beta are when we need to be cut-throat. Given that this time the 
"must-have" feature is already in the tree, I think you will find people coming 
around quickly to the side of pushing things out rather than fighting to get 
things in.  

Just my .02

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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-10 06:38:07
Subject: Re: damage control mode
Previous:From: Tom LaneDate: 2010-01-10 06:27:20
Subject: Re: Feature patch 1 for plperl [PATCH]

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