Re: Formatting Curmudgeons WAS: MMAP Buffers

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Formatting Curmudgeons WAS: MMAP Buffers
Дата
Msg-id BANLkTiny3rfiN6ez3EyDojhohNqY-FYnCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Formatting Curmudgeons WAS: MMAP Buffers  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Formatting Curmudgeons WAS: MMAP Buffers  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Wed, Apr 20, 2011 at 5:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

From my point of view I definitely thought the rationale for
commitfests was as a kind of checkpoint to make sure there weren't any
developers waiting for feedback for a long time. My concurrent index
build patch ended up needing to be reworked and I would have liked to
be involved but it wasn't until feature freeze that you found all
these problems and then it was too late to wait for me to recode
things instead of having you just do it.

I admit though this whole concept of "finished patches" seems foreign
to me. I always have additional stuff I want to do and if the patch
sits on the shelf I'm essentially stuck unable to work on the next
great thing that that patch enables. Developers either have the option
to go off on their own with no feedback and risk having initial
assumptions questioned later and all their work invalidated or go and
work on something unrelated leaving this direction stunted with only
one round of features implemented. I think this is how we ended up
with partitioning that's only halfway useful and selinux that had tons
of code written that needed to be reworked.

Core developers attention is precious and we can't really dictate that
Tom must respond to every email within a week or anything crazy like
that. The commitfests are a dramatic improvement over waiting until
feature freeze which was what was happening before. They also help
bring in new committers and having Robert and Heikki and Peter and
others giving substantive feedback has also improved things
dramatically.

To use a database analogy I think of the commitfests as a checkpoint
-- that doesn't mean we don't also need bgwriter and don't
occasionally need to flush dirty buffers to enable the database to
make progress in the mean-time. But if we didn't have checkpoints at
all things would definitely fall through the cracks and get lost to
bitrot and brainfade.

--
greg


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

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