Postgres tracking - the pgtrack project

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane sagely noted:
> No bug/issue tracker, or anything else, is going to be successful unless
> somebody commits enough time to make it so. I've noted a whole lot of
> enthusiasm for having a tracker in these recent discussions, but a
> remarkable shortage of individuals stepping up to do the work.

There are a number of reasons for this, not least of which is the
enormous and ever-changing requirements such a system would have to
have. My company has even offered resources to get something going,
and I think I convinced Bruce at one point of the usefulness of a
PG bug/feature tracking system. However, the problem is that existing
software is never going to be good enough.

The buildfarm is an excellent example of this. If Andrew had tried
to create it with something "off-the-shelf", it probably would have
taken longer to get started, been more complicated than it needed
to be, and would not work as well as it now does. However, it's been
a smashing success, so much so that MySQL is now envious[1] and is
trying to make their own version of it[2].

[1] http://www.jpipes.com/index.php?/archives/93-MySQL-Build-Farm-Part-1.html
[2] http://forge.mysql.com/wiki/MySQL_Build_Farm_Initiative

I've been thinking about this a lot since before the Summit, and the
only solution I see is to design something specifically for us.
Rather than get bogged down in details about how it will work and
what technologies it will be using, I'd like to share my ideas on
how it will work from an end-user perspective. There's a simple web
interface. You can use it to get the answer to questions like this:

What are all the open bugs for the current release?
Who is working on the updateable views patch?
Which bugs were fixed in 8.1.3?
What's the feature history of psql since 2003?
What are some easy TODO items that need getting done?
Just when does Tom Lane sleep?
What features were added in 8.1?
What are the current unapplied patches?
What bugs were fixed in tsearch2 from version 7.4.5 to 7.4.12?

Yes, maintaining it will be a royal pain in the butt. But my theory has
been "if you build it, they will come". It will require a lot of human
interaction, as automation only takes you so far, especially when trying
to parse mailing list messages. But if we eventually get a decent-size
group of people who each put in a little work on it, it should be
quite possible to keep it up to date. (Also, this would be a great way
for people to help the project who don't have the time and/or skills
to do coding).

The idea is to allow everything to happen as it already does, e.g. no
extra burdens for Tom, no extra processes anywhere. However, all the
existing information is gathered into one centralized and searchable place.
The primary sources will include the code, the docs, and the mailing lists.
Especially the mailing lists.

So, rather than go off in a corner and start coding, how about I start a
pgfoundry project for this and document my existing ideas? Any objections
to giving this a try?

- --
Greg Sabino Mullane greg(at)endpoint(dot)com greg(at)turnstep(dot)com
End Point Corporation 610-983-9073
PGP Key: 0x14964AC8 200609021107
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFE+Z/1vJuQZxSWSsgRAu7rAKCJcIOiw4jty0slWuEd6fNsCV8xcgCfQpEj
MBp00ZxG9B6UVAoHnSDq0W0=
=zlQm
-----END PGP SIGNATURE-----