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

Re: 8.5 development schedule

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: bruce(at)momjian(dot)us
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, jd(at)commandprompt(dot)com, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.5 development schedule
Date: 2009-07-01 22:55:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
bruce 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 early would not have significantly
> moved the release date earlier.

I see no one agrees with my analysis --- no matter;  if I unreservedly
agreed with others, I wouldn't be here.  ;-)

There has been discussion about how to be more hard-nosed about
rejecting patches.  I think it has to start with us being more
hard-nosed about giving patches feedback --- the very idea we had to
create commit-fests reflects that we historically have not done an
organized job of processing patches.

If we review patches as soon as they appear, and give rapid feedback, we
can easily reject patches that take more than a few days for the patch
author to resolve, and there would be little slippage;  the same goes
for dealing with known bugs.  I know it can be done, but I don't promise
it would be pleasant.

  Bruce Momjian  <bruce(at)momjian(dot)us>

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


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-07-01 22:57:05
Subject: Re: 8.5 development schedule
Previous:From: Kevin GrittnerDate: 2009-07-01 22:53:04
Subject: Re: 8.5 development schedule

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