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

From Christopher Browne
Subject Re: Formatting Curmudgeons WAS: MMAP Buffers
Date
Msg-id BANLkTimrVC-Aqh4nVoSMyE+LojS3oN3M2g@mail.gmail.com
Whole thread Raw
In response to Re: Formatting Curmudgeons WAS: MMAP Buffers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Apr 21, 2011 at 11:05 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I agree.  I am in favor of a shorter release cycle.  But I think that
> a shorter release cycle won't work well if there is still four month
> long integration period at the end of each series of CommitFests.  The
> problem is a bit circular here: because release cycles are long,
> people really, really want to slip as much as possible in at the end.
> But being under time pressure to get things committed results in a
> higher bug count, which means more things that have to be fixed after
> feature freeze, which translates into a long release cycle.

If we somehow were able to come up with a 6 week release cycle, we'd
still have the problem that there are features that take more than 6
weeks to integrate into a release.  (HOT and SyncRep, I'm looking at
you!) Any such larger features would "blow this up," quite forcibly.

I don't think our release cycle is vastly too long; it takes enough
time to plan upgrades for systems that my colleagues at Afilias aren't
keen on using every PG release in production that comes out as it
stands now.

Peter Eisentraut points out that with the way things are, now,  "...
you are left with all of about 20 days per year for discussion,
collaborative planning and coding.  Which is obviously silly, which is
why the process breaks down."

I think the CommitFests have been a *super* tool for addressing such
problems as:
- patches getting lost
- getting review effort put onto the easier patches

But they aren't the only thing we conceptually need to have.  For
tougher features, they're not great.  And they're completely useless
at addressing discussions surrounding things we know we want done, but
don't have a strategy for yet.  Those things aren't "patches", there's
nothing yet to commit.

My sense is that something else is needed as a process to help with
those "nebulous large changes."  I'm not sure quite what it looks
like.  Maybe there's some tooling that would be helpful, but we really
need some experimentation to figure out what the process should look
like.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: my signature
Next
From: Josh Berkus
Date:
Subject: Re: EOL for 8.2 (was Re: Formatting Curmudgeons WAS: MMAP Buffers)