Re: Formatting Curmudgeons WAS: MMAP Buffers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(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>
Subject: Re: Formatting Curmudgeons WAS: MMAP Buffers
Date: 2011-04-21 15:46:49
Message-ID: 23281.1303400809@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[ another thought on this topic ]

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think that it's not too bad if the process of a release getting out
> the door results in effectively missing one CommitFest. ...
> But that isn't going to work if people do
> the same sort of throwing everything into the kitchen sink at the last
> minute that we have been doing for at least the last couple of
> releases.

> In fact, I don't believe that the current CF cycle really forces a
> huge amount of waiting-for-feedback. It's true that if you submit a
> patch at a randomly chosen time, you will have to wait up to two
> months for a CommitFest to start, and then you might not get a review
> until late in the CommitFest, so it could take you up to three months
> to get a review. In practice, patches are not submitted at random
> times - in fact, probably 50% of the patches come in during the last
> week before the CF starts, and typically perhaps 50% of the patches
> get a review in the first week, and maybe 80% within the first two
> weeks.

But aren't those two sides of the same coin, ie, people's natural
tendency to work to a deadline? If you approve of a lot of patches
showing up just in time for a commitfest, why don't you approve of
big patches showing up just in time for a release? I mean, I've been
heard to complain about that too, but complaining hasn't changed
anyone's behavior and it's foolish to expect that it will in the
future. (See insanity, definition of.)

We need to find a way to work with that behavior, not try to change it.
I don't know what exactly.

One idea that comes to mind is to give up on the linear development-mode-
then-beta-mode management model, ie, allow development of release N+1
to start while beta is still going on for release N. The principal
objection to this in the past has been that the PG development community
is too small to do more than one thing at once, but maybe that's not
true anymore. The thing I'd be most worried about is how we get enough
energy directed at the release-stabilization part of the work, when for
most developers the new-development part is much more interesting/fun.
But we have that problem in some form already --- it's not clear to me
how much of the community really engages in what happens during beta,
rather than quietly working on stuff for the next release.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2011-04-21 15:48:28 Re: Formatting Curmudgeons WAS: MMAP Buffers
Previous Message Robert Haas 2011-04-21 15:46:30 Re: getting to beta