public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Tom Lane <[email protected]>
Cc: Josh Berkus <[email protected]>
Cc: [email protected]
Subject: Re: Feature freeze progress report
Date: Wed, 02 May 2007 09:23:49 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

Tom Lane wrote:
> Josh Berkus <[email protected]> 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

view thread (98+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Feature freeze progress report
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox