Tom Lane wrote:
> > As for thresholds, I'd propose that we measure the size of patches
> > using "diff -u | diffstat".  If the number of insertions plus the
> > number of deletions is >= 1000, then the patch is not eligible for the
> > final CommitFest unless it was submitted for the penultimate
> > CommitFest.  This obvious discriminates against patches with a large
> > footprint that are not very invasive and in favor of those with a
> > small footprint that are more destabilizing, but it's a clean line in
> > the sand, and I think having such a line is better than trying to
> > apply human judgment to every case.
> 
> Well, in the end it will come down to committers' judgements anyway;
> if someone thinks a patch is ready it will probably go in, regardless
> of size.  But this gives us another tool for saying "no", so I'm
> agreeable ;-)

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.

-- 
  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-06-30 17:21:14 from Tom Lane

Responses

• Re: 8.5 development schedule at 2009-07-01 04:20:53 from Robert Haas
• Re: 8.5 development schedule at 2009-07-01 14:30:39 from Kevin Grittner

pgsql-hackers by date

Next:	From: Robert Haas	Date: 2009-07-01 04:20:53
	Subject: Re: 8.5 development schedule
Previous:	From: Stephen Frost	Date: 2009-07-01 02:57:50
	Subject: Re: 8.5 development schedule