Re: Formatting Curmudgeons WAS: MMAP Buffers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Formatting Curmudgeons WAS: MMAP Buffers
Дата
Msg-id 24890.1303194874@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Formatting Curmudgeons WAS: MMAP Buffers  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Formatting Curmudgeons WAS: MMAP Buffers  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> I received a private offlist email from someone who didn't feel
> comfortable bringing up their issues with this list publicly.  Let me
> quote from it, because I think it pins part of the issue:

> "I believe this is due to the current postgresql "commitfest" process
> whereby there is no real way to present new ideas or technologies
> without coming to the table with a fully-baked plan and patch. This is
> obvious even in the name "commitfest" since the expectation is that
> every patch presented is considered ready-to-commit by the patch
> presenter. This makes a novice or experimental contribution less likely."

As Robert noted, the purpose of the commitfest mechanism is mostly to
ensure that patches that *are* committable, or close to it, don't fall
through the cracks.  I'm not sure we're doing anybody any favors by
trying to shoehorn reviews of WIP ideas into that same process.  At the
very least it seems we'd need a different set of review guidelines for
WIP items, and we don't have one.

I think useful reviewing of WIP stuff has to focus much more on design
concepts and much less on code reading.  The reason why the mmap patch
was getting such negative feedback was that there was no way to provide
such a review except by reverse-engineering the design out of some very
messily-presented code.  So if we're going to do anything about this,
what we have to do is tell people that the first thing to present for
a WIP review is a design document.  If they feel a need to write some
throwaway code to help them clarify their ideas, fine ... but *don't
show us that code*.  Write a design document.  Get that reviewed.
Then see about coding it, or bringing your first-draft code up to the
point where it can stand the light of day.

I don't know if we need a formal process akin to CFs for reviewing
design documents.  I think people are usually plenty willing to discuss
ideas on -hackers, unless maybe you hit them at a particularly bad time
like when they're already burnt out towards the end of a CF.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [JDBC] JDBC connections to 9.1
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Windows 64 bit warnings