Following some public and not so public discussion a little while back,
I decided to ask a group of people to help me to create an
experimental tracker instance for bugs and possibly features, to assist
our development efforts. The people I chose were some I have worked with
before, e.g. on the buildfarm, or who had expressed general support for
the idea, and who I thought could usefully contribute to such a project.
The idea is to run this for one release cycle, at the end of which time
we should have enough experience to know if it could help or hinder our efforts.
At the moment we are still discussing both scope and software
candidates, and exploring a couple of candidates.
There is no intention to be secret, but we also don't want to be
endlessly debating possible merits, which has been an unfortunate
characteristic of several discussions over the years. Rather, we want to
demonstrate what we believe to be the benefits, as clearly and directly
as possible, by actual use.
We currently have a project on pgfoundry, including a mailing list, at
http://pgfoundry.org/projects/tracker/ and a wiki at
Anyone who is interested in contributing is welcome to join in,
especially if they have a history of involvement in PostgreSQL
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2007-06-03 02:15:35|
|Subject: Re: syslogger line-end processing infelicity|
|Previous:||From: Tom Lane||Date: 2007-06-02 22:28:55|
|Subject: Re: Tsearch vs Snowball, or what's a source file? |