From: Gregory Stark <stark@enterprisedb.com>
To: "Bruce Momjian" <bruce@momjian.us>
Cc: "Josh Berkus" <josh@agliodbs.com>,  <pgsql-hackers@postgresql.org>
Subject: Re: Feature freeze progress report
In-Reply-To: <200705021046.l42Akk127514@momjian.us> (Bruce Momjian's message
	of "Wed, 2 May 2007 06:46:45 -0400 (EDT)")
Organization: EnterpriseDB
References: <200705021046.l42Akk127514@momjian.us>
Date: Wed, 02 May 2007 12:59:27 +0100
Message-ID: <87k5vrh1wg.fsf@oxford.xeocode.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


"Bruce Momjian" <bruce@momjian.us> writes:

> We seem to handle trivial patches just fine.  

You keep saying that but I think it's wrong. There are trivial patches that
were submitted last year that are still sitting in the queue.

In fact I claim we handle complex patches better than trivial ones. HOT, LDC,
DSM etc receive tons of feedback and acquire a momentum of their own.
Admittedly GII is a counter-example though.

On the other hand trivial patches tend to interest relatively few people and
have little urgency.

> The current problem is that the remaining patches require domain or
> subsystem-specific knowledge to apply, e.g. XML or WAL, and those skills are
> available in a limited number of people. If I had the expertise in those
> areas, I would have applied the patches already.

Well, I claim it's often the trivial patches that require the domain-specific
knowledge you describe. If they were major patches they would touch more parts
of the system. But that means they should be easy to commit if you could just
fill in the missing knowledge.

Could you pick a non-committer with the domain-specific knowledge you think a
patch needs and ask for their analysis of the patch then commit it yourself?
You can still review it for general code quality and trust the non-committer's
review of whether the domain-specific change is correct.
 
-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com