Re: Sync Rep for 2011CF1

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: Sync Rep for 2011CF1
Дата
Msg-id AANLkTikE-kv_+Uhgx+3A3Wk7tLsm0W=eQ-o5q=v8E1S+@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Sync Rep for 2011CF1  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> ... Well, the current CommitFest ends in one week, ...
>>
>> Really?  I thought the idea for the last CF of a development cycle was
>> that it kept going till we'd dealt with everything.  Arbitrarily
>> rejecting stuff we haven't dealt with doesn't seem fair.
>
> Uh, we did that with 8.4 and it was a disaster.  The CommitFest lasted
> *five months*. We've been doing schedule-based CommitFests ever since
> and it's worked much better.

Rejecting stuff because we haven't gotten round to dealing with it in
such a short period of time is a damn good way to limit the number of
contributions we get. I don't believe we've agreed at any point that
the last commitfest should be the same time length as the others (when
we originally came up with the commitfest idea, it certainly wasn't
expected), and deciding that without giving people advanced notice is
a really good way to piss them off and encourage them to go work on
other things.

If we're going to put a time limit on this - and I think we should -
we should publish a date ASAP, that gives everyone a fair chance to
finish their work - say, 4 weeks.

Then, if we want to make the last commitfest the same length as the
others next year, we can make that decision and document those plans.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Sync Rep for 2011CF1
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: SQL/MED - file_fdw