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

Re: 8.5 development schedule

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-02 02:14:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
> 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.

Also agreed.  It's never pleasant to have a patch rejected/postponed,
but it's tolerable if you've gotten some feedback and understand the
reasons why.  Of course there is no guarantee that you will agree with
those reasons, but that's life.  Some day you may be the committer and
have your turn to irritate patch submitters.  :-)


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-07-02 02:25:41
Subject: Re: gin--a rule for function parameter
Previous:From: Fly.LiDate: 2009-07-02 01:49:48
Subject: Re: gin--a rule for function parameter

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