Re: 8.4 release planning

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jd(at)commandprompt(dot)com, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: 8.4 release planning
Date: 2009-01-29 13:19:05
Message-ID: 603c8f070901290519q694a1d87kcd505ca295631af1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> read up-thread, i've already shown that this would not be the case. remember,
> we reduce the pressure from the large, complex patches that bottleneck the
> process, which allows more parralell review/commit.

I read what you wrote - I just don't believe it. My own experience is
that doing more releases is more work. Also, two commitfests per
release means that if you can't get your patch up to snuff in two
iterations, you're bumped. The diminished pain of being bumped will,
I think, be more than balanced out by the increased frequency of
bumps. Many patches needed 2 or 3 commitfests to get committed; all
of the people who need 3 iterations, and anyone who needs 2 iterations
and doesn't submit until the second commitfest of the cycle, will take
two releases to get out the door. I don't believe you're ever going
to make beta/release so low-impact that that won't be disruptive or
irritating to people.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-01-29 13:31:49 Re: Hot standby, recovery infra
Previous Message Zdenek Kotala 2009-01-29 13:15:01 Re: pg_upgrade project status