Re: Formatting Curmudgeons WAS: MMAP Buffers - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund <andres@anarazel.de> wrote:
>> On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote:
>>> Yeah, maybe.  To do that, we'd have to strongly resist the temptation to
>>> spend a lot of time fixing up submitted patches --- if it's not pretty
>>> darn close to committable, back it goes.  But that might be a good thing
>>> all around.  I find this idea attractive.

>> Actually as a patch submitter I would somewhat prefer that as well. Its not
>> exactly easy to learn what wasn't optimal with your patch at times.
>> On the other hand for some issues its pretty hard to fix the more involved
>> issues without e.g. Tom's involvement.

> This would amount to reducing the amount of time we spend
> in-CommitFest from 50% to slightly less than 25%.  That would
> certainly be pleasant from my point of view, but for the average patch
> to get the same amount of attention, we'd need twice as many
> volunteers, or the existing people to volunteer twice as much time, or
> everyone to work twice as fast as they already are.

Well, no, that's not the whole story.  To me, what the above idea
implies is shifting more of the burden of fixing up patches away from
the committer and back to the patch author.  Instead of spending time
fixing up not-quite-ready patches myself, I'd be much more ready to
tell the patch author "do X, Y, and Z, and come back next month".

From the committers' standpoint, this is a great idea precisely because
it suggests we might get to put only 25% and not 50% of our time into
commitfests.  But it also makes the work more distributed, and it forces
patch authors to learn the things that committers might otherwise have
done for them silently, which in the long run will make everything work
better.

The key point is that we do have to have much more frequent commitfests.
It's hard to bounce back a patch when you know it will then be delayed
two months, especially if the patch is already two months old and the
author has probably forgotten half of it himself.  For me anyway,
"I'll just take half a day and make this look the way I think it should"
is a continual temptation.  A shorter CF cycle would weaken the argument
to do that.

I haven't spent any time in the role of a non-committer reviewer, but
I think that the same dynamic might work for reviewers.  Basically
what a short cycle would do is encourage people to hit the high points
and turn the review around quickly, dumping the big issues back into the
patch author's lap for fixing.  You wouldn't spend time sweating details
until the patch had gotten into a state that justified it.  Of course
we'd need to tweak the review guidelines to encourage this sort of
multiple-iterations review approach --- right now the guidelines are
pretty much one-size-fits-all, and this type of approach cannot work
with that.
        regards, tom lane