To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgresql.org,  Tom Lane <tgl@sss.pgh.pa.us>,
	josh@agliodbs.com,  Bruce Momjian <bruce@momjian.us>
Subject: Re: Getting a move on for 8.2 beta
References: <200609012225.k81MPwJ02170@momjian.us>
	<200609011639.42280.josh@agliodbs.com>
	<26043.1157154656@sss.pgh.pa.us> <200609020209.36483.peter_e@gmx.net>
From: Gregory Stark <gsstark@mit.edu>
In-Reply-To: <200609020209.36483.peter_e@gmx.net>
Date: 02 Sep 2006 00:03:17 -0400
Message-ID: <87zmdi530a.fsf@stark.xeocode.com>
Lines: 38
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Peter Eisentraut <peter_e@gmx.net> writes:

> Tom Lane wrote:
> > Well, no, it's not.  We have told people till we're blue in the face
> > "post early, post often".  Now I will plead guilty to not always
> > having spent as much time giving feedback on draft patches as I
> > should've, but the process is pretty clear.  As I see it the main
> > problem is people undertaking patches off in corners somewhere rather
> > than discussing their work on the mailing lists while they do it.
> 
> Again, process support.  If all we can offer people is to post 
> multi-megabyte patches to the mailing list every month, that totally 
> doesn't help.  

You're right, it's a pain for developers to have to keep shipping around
patches over and over. It means anyone else who wants to look at your code is
probably looking at an old version, there's no convenient way to convert from
incremental patches to cumulative patches, etc.

There are tools to solve this but they're not "process support", they're
revision control systems. If CVS didn't suck so hard I would suggest that the
natural thing to do would be to grant CVS access far and wide and have people
create branches for their proposed changes. The existing set of committers
would become the set of people allowed to commit to HEAD. Sadly CVS makes this
about as much work as the current system and the risks are much higher.

> We'd need ways to track the progress on these things: 
> what was the specification for that patch, where was the discussion on 
> it, what has changed in the patch since the last time, since the time 
> before last time, what is left to be done, who has worked on it, etc.  
> Figuring out the answer to those questions from a mailing list archive 
> is tedious to the point that no one wants to do it.

Frankly these things all sound pretty trivial. 

-- 
greg