Re: Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.)

Well, I guess I approve of the first behavior because it doesn't feel
like having a red-hot iron spike driven through my foot, and I
disapprove of the second one because it does. That may not be
entirely consistent taken in the abstract, but it has some solid
practical roots.

> 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.

I totally agree. In fact, I think that trying to close off that
activity is one of the most self-destructive things we could possibly
do. It makes missing the release far more painful if you're thinking
about not only a 12-month slip on GA but also a 6-month slip on any
meaningful further review. Encouraging people to hold off major
proposals for the next release while we are focusing on beta also
tends to slow them down, which then exacerbates the pile-up at the end
of the release cycle. I would like to blow the doors on that wide
open and encourage people to start submitting design proposals for 9.2
NOW. NOW, NOW, NOW! Not in July! And *really* not next January!
And frankly, the sooner we can realistically start working on
integrating the code that has *already* been written for 9.2, the
better. The patches are going to land on us at some point, and
dealing with them earlier will allow those people to move on to other
things (which is good), reduce the pile-up at the end of the cycle
(even better), or possibly both.

I'm willing to make a serious commitment to being involved in the
release stabilization work and to give it some degree of priority over
new patches, if that's what it takes to make the process work
smoothly. We are fundamentally resource-constrained, and no process
is going to change that unless the process change, of itself, causes
more people to contribute more time. But even if the first CommitFest
involves a slightly higher bounce rate due to lack of
reviewer/committer bandwidth, it's still better than not having one.
There have been maybe half a dozen people who have been principally
responsible for the stabilization that we have done since CF4, and the
community is much larger than that. Everyone else is either doing
nothing (which is bad), or working without on-list discussion (which
is also bad). Even for the people who are deeply committed to release
stabilization would probably be happier and more motivated to continue
contributing if they weren't being limited to ONLY that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company