Re: Commit fest queue - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Commit fest queue
Date
Msg-id 87hceauii6.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Commit fest queue  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: Commit fest queue  ("Tom Dunstan" <pgsql@tomd.cc>)
Re: Commit fest queue  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
"Stefan Kaltenbrunner" <stefan@kaltenbrunner.cc> writes:

> Tom Dunstan wrote:
>> What's wrong with a patch submitter submitting a patch to a tracker,
>> but then emailing the list for actual discussion? 

What's what we have today with the wiki. We don't need any special software to
do that. It does require some patch queue maintainer(s) to make sure things
get added or updated.

> well what about having the tracker being subscribed to the list and let it
> create a bug/patch/ticket id automatically for new mails - that way all stuff
> is automatically tracked ? - That way it can be categorized in the course of
> the following discussion but no history gets lost.

This requires an AI which passes the turing test. How do you determine what
patch is related to and how it affects the status of that patch? This is
precisely the work Bruce was doing previously and it's a lot of work. This is
precisely what we're asking people to do on the wiki now.

Bug/request trackers are great tools, but they're just tools. They don't
replace actually having to do the work. Given the really trivial number of
patches we're dealing with really just adding entries to a wiki page is a
perfectly reasonable solution.

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


pgsql-hackers by date:

Previous
From: Thomas Burdairon
Date:
Subject: Re: [JDBC] Re: How embarrassing: optimization of a one-shot query doesn't work
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: Commit fest queue