Re: Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>> I think to really address that problem, you need to think about shorter
>>> release cycles overall, like every 6 months.  Otherwise, the current 12
>>> to 14 month horizon is just too long psychologically.
>
>> I agree.  I am in favor of a shorter release cycle.
>
> I'm not.  I don't think there is any demand among *users* (as opposed to
> developers) for more than one major PG release a year.  It's hard enough
> to get people to migrate that often.

I agree there's probably little user demand, and back-branch
maintenance is an issue, but I think if it removed the temptation to
cram major new features into the tree at the last minute, it might be
worth it. However, a possibly more likely outcome is that we'd still
have that temptation, just more frequently; and end up with even less
of the year open to new patches than is currently the case.

> Another problem is that if you halve the release interval, you either
> double the amount of work spent on maintaining back branches, or halve
> the support lifetime of a branch.  Neither of those is attractive.
>
> Now, it certainly would be nice to spend less time in beta mode as
> opposed to development, and I think most of the points being made here
> are really about how to cut that.  But reducing the release interval is
> not going to reduce the total amount of time we spend in beta mode;
> in fact I'd expect it to increase.  Halving the amount of development
> time per release doesn't mean that you can cut beta time proportionally.
> It just takes time to cut a release, and time for testers to try it.

I believe that the problem is much more related to the fact that we
commit things at the end of the cycle that aren't really done than it
is to the amount of time beta testers need to try things. If we were
only waiting on testing, we could branch the tree and call the release
du jour beta for another N months, then release, meanwhile continuing
development. In fact, you and I and three or four other people have
spent most of our visible PG time over the last 2 months fixing MANY
bugs, mostly in the six or so major features committed between
February 7th and March 6th. (By way of comparison, notice how few
bugs that have been in the major patches from CF3 - because those
things were actually pretty much working *when they were committed*.)

Now, we're getting to the point where that might actually be a
reasonable way to go. It wouldn't bother me a bit to branch the tree
just after beta1 and start a new cycle of CommitFests on May 15th, and
we could begin integrating some of the big stuff that didn't make it
into 9.1: key locks, range types, additional sync rep modes, snapshot
cloning, parallel pg_dump, etc. It would be great to start working on
that stuff while it's still mildly fresh in people's minds, and at the
*beginning* of the release cycle. We're probably doomed to another
fall release at this point anyway, so it's not clear to me that the
inevitable loss of focus that will ensue is really costing anything.
Had we gotten to beta1 on March 1st, I'd probably be in favor of going
all in to get the release out in June or maybe on July 1, but at this
point that seems unlikely to be realistic.

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