To: "Alvaro Herrera" <alvherre@commandprompt.com>
Cc: "Bruce Momjian" <bruce@momjian.us>,  "Tom Lane" <tgl@sss.pgh.pa.us>,
	"Greg Smith" <gsmith@gregsmith.com>,
	"Pg Hackers" <pgsql-hackers@postgresql.org>
Subject: Re: Patch queue -> wiki
In-Reply-To: <20080408124149.GD5290@alvh.no-ip.org> (Alvaro Herrera's message
	of "Tue\, 8 Apr 2008 08\:41\:49 -0400")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <27307.1207361987@sss.pgh.pa.us>
	<200804050236.m352aTY00979@momjian.us>
	<20080408124149.GD5290@alvh.no-ip.org>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Tue, 08 Apr 2008 14:11:30 +0100
Message-ID: <87y77o4hkt.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Alvaro Herrera" <alvherre@commandprompt.com> writes:

> FWIW I've been asking patch submitters (privately) to add the patches
> they submit to the May commitfest pages, and they've mostly done it
> right away.  If you click the history link on the May page you can see
> changes from Pavel Stehule, Teodor, Andrew Dunstan, Greg Start and Tom
> -- so we already have a reasonably complete overview of what we need to
> do on the next commitfest.  I don't expect this to be a one-time affair.

I think asking submitters to add their patches is a good idea and in fact
Heikki's suggestion of having the wiki be primarily driven by submitters is a
good idea. It gives people a central place to go back and check and find all
the collected reviews and CVS status of their work and keeps us honest.

I would like to suggest a few attributes we want for each patch:

1) Patch maturity (whether it was proposed as a design, WIP, or submission for
   committing).

2) Reviewers interested in working on the patch. I think it would help
   organize ourselves and make sure all the patches get covered. Also, it
   would help get people involved who are otherwise overtaken by more "senior"
   postgres hackers. Those hackers would probably focus on patches that were
   beyond the ability of more "junior" hackers and were otherwise getting
   ignored.

3) Committers working on integrating the code. No point in risking duplication.

My first instinct is to convert it to a table. But perhaps we could just stick
these attributes in the current format as sublist items under each major
bullet point.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's Slony Replication support!