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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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