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 or flat)
Thread:
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
here.

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
reviewed?

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

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           www.2ndQuadrant.com
 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-2014 The PostgreSQL Global Development Group