Kevin Grittner wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote: 
>  
> > I realize there is the perception that the large patches that were
> > eventually rejected held up the release, but for all the patches I
> > can think of, they were not rejected immediately _because_ we had
> > other valid patches to work on.  Once all valid patches were
> > applied, we were quickly able to reject the large unready patches.
> > 
> > So, rejecting the large patches earily would not have significantly
> > moved the release date earlier.
>  
> Like Robert, I'm extremely skeptical of this claim, for the same
> reasons.
>  
> However, even the *possibility* that this could be true is pretty
> scary.  If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

We had many patches that had been through previous commit-fests with
minor adjustments and we had to finalize them before we could close the
final commit-fest.  To be clear I am talking about patches that were
eventually applied in 8.4, not patches that were rejected for 8.4.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

• Re: 8.5 development schedule at 2009-07-01 14:30:39 from Kevin Grittner

Responses

• Re: 8.5 development schedule at 2009-07-01 17:39:19 from Kevin Grittner
• Re: 8.5 development schedule at 2009-07-01 21:01:04 from Tom Lane

pgsql-hackers by date

Next:	From: David E. Wheeler	Date: 2009-07-01 17:35:10
	Subject: 8.3 PLpgSQL Can't Compare Records?
Previous:	From: Alvaro Herrera	Date: 2009-07-01 17:31:41
	Subject: Re: 8.5 development schedule