Skip site navigation (1) Skip section navigation (2)

Re: 8.5 development schedule

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.5 development schedule
Date: 2009-07-01 09:57:40
Message-ID: 1246442260.27964.272.camel@dn-x300-willij (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, 2009-07-01 at 02:14 -0400, Robert Haas wrote:

> Basically, if we're too quick to bump patches to the next CommitFest,
> there will be only moderate resistance for the first N-1 CommitFests,
> but then for the last CommitFest people won't want to be bumped by a
> whole major release for what are basically minor issues.

That is an important point. Remember we are talking about non-committers

Each commitfest needs to be about wrangling in the patches that are
exact or nearly there. Nothing is perfect, especially when the
definition of perfection is not controlled by the patch author. How can
anybody know what will or will not be objected to until the patch is

Committers don't submit perfect patches, they apply them piece by piece,
with comments about "I'll get back to that" or "still thinking of best
way to do it.". Look at the way FOREIGN DATA WRAPPERS got in. Half a
feature, piece by piece (I have zero objection to that, just an

Saying that non-committers need to submit perfect patches or we reject
them just ends up with a pile up. Expecting people that haven't passed a
the bar exam to provide a higher standard of code than those that have
passed the test is obviously not going to work.

 Simon Riggs 
 PostgreSQL Training, Services and Support

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-07-01 14:01:58
Subject: Re: Extensions User Design
Previous:From: Fly.LiDate: 2009-07-01 09:54:31
Subject: gin--a rule for function parameter

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group