DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
	b=Pmb8drt4AsagML8Jne65iE33GTpaPbJZincnVRauvIIgHyL4aByjWUJm8WOgBB+t6zfjFdcGDrBN21757cFIRUgOYeTMqN4PwQstxC7iwDYQxZ+mLPNX6GbFNH/rYdvoaVmUL4B51IcSfD0l2UMIyNKcPlq6E+0qgUZ8R6vm0rY=
Message-ID: <46384A95.5030809@enterprisedb.com>
Date: Wed, 02 May 2007 09:23:49 +0100
From: Heikki Linnakangas <heikki@enterprisedb.com>
User-Agent: Icedove 1.5.0.10 (X11/20070329)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Josh Berkus <josh@agliodbs.com>,  pgsql-hackers@postgresql.org
Subject: Re: Feature freeze progress report
References: <200705012309.l41N9O908241@momjian.us>
	<200705012151.51915.josh@agliodbs.com>
	<5678.1178083185@sss.pgh.pa.us>
In-Reply-To: <5678.1178083185@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> Actually, that can happen with the current system. The real blocker there is 
>> that some people, particularly Tom, work so fast that there's no chance for a
>> new reviewer to tackle the easy stuff.  Maybe the real solution is to 
>> encourage some of our other contributors to get their feet wet with easy 
>> patches so that they can help with the big ones later on?
> 
> Yeah, I hear what you say.  This is particularly a problem for small bug
> fixes: I tend to zing small bugs quickly, first because I enjoy finding/
> fixing them and second because I worry that they'll fall off the radar
> screen if not fixed.  But I am well aware that fixing those sorts of
> issues is a great way to learn your way around the code (I think that's
> largely how I learned whatever I know about Postgres).  I'd be more
> willing to stand aside and let someone else do it if I had confidence
> that issues wouldn't get forgotten.  So in a roundabout way we come back
> to the idea that we need a bug tracker (NOT a patch tracker), plus
> people putting in the effort to make sure it stays a valid source
> of up-to-date info.  Without the latter it won't really be useful.

A great way to learn would be to look at the patches in the queue, and 
find bugs in them. There's a lot more bugs to be found in submitted 
patches than in PostgreSQL itself. A patch tracker would help with that.

I'm in favor of some kind of a patch tracker. It doesn't need to be too 
fancy, but if for each patch we had:

Patch name:	Kitchen sink addition to planner
Latest patch:	kitchen-sink-v123.patch, click to download
Summary:	Adds a kitchen-sink node type to the planner to enable liquid 
queries.
Status:		Will be rejected unless race conditions are fixed. Needs 
performance testing.
Discussions:	<links to mail threads, like in the current patch queue>

That wouldn't necessarily help committers directly, but it'd give more 
visibility to the patches. That would encourage more people to review 
and test patches. And it'd make it clear what the status of all the 
patches are to anyone who's interested.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com