Re: Formatting Curmudgeons WAS: MMAP Buffers

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Formatting Curmudgeons WAS: MMAP Buffers
Дата
Msg-id BANLkTi=L2_kH4uF1dQT1XWXW2sM-aTNmQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Formatting Curmudgeons WAS: MMAP Buffers  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Formatting Curmudgeons WAS: MMAP Buffers  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Wed, Apr 20, 2011 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> I think this is historical revisionism. ...
>> Somewhere down the line this seems to have been forgotten and we are now
>> using commitfests just to track finished patches.
>
>> So if we want to stick to the original principles we should have some
>> sort of "different set of review guidelines".  Or perhaps we could just
>> decide that we don't care much about this problem and toss it aside.
>
> Well, I absolutely think that we need to encourage people to get
> feedback at the design and prototype stages.  The problem with the
> commitfest mechanism for that is that when you are trying to work out a
> patch, you don't want to wait around for a couple months for comments.
> The time delay that's built into the CF process means that it's
> fundamentally not very good for anything except finished patches that
> can sit on a shelf for awhile before they get applied.
>
> I think that ideally, WIP reviews would be something that happens
> quickly on pgsql-hackers, and probably it would be best if they were
> explicitly *not* encouraged while a CF is on.  I know that I tend to see
> discussions of unfinished patches as something of a distraction when
> I'm up to my ears in committing finished ones, and certainly there's
> less mental bandwidth available then.

Ditto.

Unfortunately, my memory of this project only goes back to about
September 2008, which isn't far enough to remember why CommitFests
were created in the first place.  So Alvaro may be correct in saying
that things have mutated over time, but that isn't necessarily a bad
thing.  Maybe we've settled into something that works reasonably well.Or maybe we should make some changes; nothing is
setin stone. 

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pgindent weirdness
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgindent weirdnessf