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

Re: damage control mode

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: damage control mode
Date: 2010-01-09 02:01:09
Message-ID: 603c8f071001081801k63526e47lbab20ec58f084803@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jan 8, 2010 at 7:48 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On fre, 2010-01-08 at 10:02 +0100, Dimitri Fontaine wrote:
>> Now, I'll second Greg Smith and Tom here, in that I think we need to
>> run
>> the last commitfest as usual, knowing that the outcome of the
>> commitfest
>> for any given patch is not "it made it" but "we reviewed it". It's
>> still
>> right for the project to bump a patch on resources ground rather than
>> on
>> technical merit, at the end of the commitfest.
>
> +1, leave everything as is.
>
> The commitfest is a tool for people to track what is going on, not a
> tool to tell people what to do.

I don't understand what you mean by this.  Can you please elaborate?

It's obvious to me that there is a strong consensus against bumping
any patches from the final CommitFest at this point.  Most people seem
to feel that this is premature, and some people seem to find it
outright ludicrous.  I don't really understand why.  I have always
felt that the purpose of a CommitFest was to give everyone a fair
shake at getting their patch reviewed, provided that they followed
certain ground rules.  And I thought we had agreement that one of
those ground rules was "don't submit new, large patches to the final
CommitFest in a particular release cycle".  No?

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-09 02:10:08
Subject: Re: We need to rethink relation cache entry rebuild
Previous:From: Greg StarkDate: 2010-01-09 01:58:53
Subject: Re: We need to rethink relation cache entry rebuild

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