Re: Getting a bug tracker for the Postgres project

All,

Let me mention some of the reasons we as a project could use a bug
tracker which have nothing to do with actually fixing bugs.

(1) Testing: a bug tracker could be used for beta testing instead of the
ad-hoc system I'm writing. Assuming it has the right features, of course.

(2) User information: right now, if a user has an issue, it's very very
hard for them to answer the question "Has this already been reported
and/or fixed in a later release." This is a strong source of
frustration for business users who don't actively participate in the
community, a complaint I have heard multiple times.

(3) Lack of a bug tracker with a web services API prevents downstream
projects (PostGIS, RHEL, Ubuntu, Django, Drupal, etc.) from linking in
PostgreSQL bug reports which affect their users. Also, because these
projects are used to bug trackers, they get confused when they need to
report a bug to us.

(4) Because having a bug tracker is seen as standard and mainstream
among OSS projects, the fact that we don't have one is regarded as
oddball and backwards, and does result in some companies choosing not to
use PostgreSQL because we're perceived as "too weird" and
"anti-commercial".

Where *fixing* bugs is concerned, I'm concerned that a bug tracker would
actually slow things down. I'm dubious about our ability to mobilize
volunteers for anything other than bug triage, and the fact that we
*don't* triage is an advantage in bug report responsiveness (I have
"unconfirmed" bugs for Thunderbird which have been pending for 3 years).
So I'm skeptical about bug trackers on that score.

However, for the four non-fixing items, having some kind of bug tracker
would be a real asset to the project. I'm just not sure what kind of
bug tracker that would be.

BTW, we talked to Debian about debbugs ages ago, and the Debian project
said that far too much of debbugs was not portable to other projects.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com