Re: Formatting Curmudgeons WAS: MMAP Buffers

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dan Ports <drkp(at)csail(dot)mit(dot)edu>, Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>, andrew <andrew(at)dunslane(dot)net>, cbbrowne <cbbrowne(at)gmail(dot)com>, greg <greg(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Formatting Curmudgeons WAS: MMAP Buffers
Date: 2011-04-20 16:52:37
Message-ID: BANLkTiny3rfiN6ez3EyDojhohNqY-FYnCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 20, 2011 at 5:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aidan Van Dyk 2011-04-20 17:03:14 Re: pgindent weirdness
Previous Message Andrew Dunstan 2011-04-20 16:38:57 Re: pgindent weirdness