Greg,
> I'm rather surprised Postgres doesn't have a good bug tracking system.
> That's something most projects find pretty essential. Strangely enough the
> reason seems to be that Postgres really doesn't have many bugs... Unlike
> web browsers or GUIs or most of the other free software projects out there,
> databases don't tolerate bugs well. Any serious bug is cause for an
> immediate point release. The only use for a bug tracking system would
> really be for tracking all those pesky "IWBNI" bugs that never rise to
> urgent status.
Actually, a bug tracker would be useful for two purposes:
1) Tracking bugs that are actually feature requests, in an effort (possibly
futile) to cut down on the number of "when will PostgreSQL be able to use an
index on MAX()?" requests that we get. A certain amount of this is in our
FAQ, but the FAQ has the flaws of both not being easily searchable, and
having a very manual update process so that it frequently gets out of date.
2) Tracking bugs that were fixed (and features that were added) in particular
releases so that users know when they need to upgrade. For example, if a
user had an index corruption problem with 7.4.1, it would be useful for them
to know that an upgrade to 7.4.5 (as I recall) would fix it. Currently,
they'd have to read all of the release notes from 7.4.2 through 7.4.5 and
decipher insider terminonolgy to figure it out -- not always easy to do, and
even harder to convince your boss.
The problem is that a bug tracker would not be useful to the Postgresql
*developers*; our current system works pretty well for us now. Except for
one possibility:
IF we had a formal bugtracker, are there people who are not currently
contributing to PostgreSQL who would be willing/able to read, test, and
analyse bug reports? With the addition of several companies to our
community, it's a possibility, and would make the trouble of using a bug
tracker worthwhile, I think.
Comments?
--
Josh Berkus
Aglio Database Solutions
San Francisco
