Re: Bug tracking system policy

First, thanks for installing a bug-tracking system.

Writing from an end-user's perspective, I agree and support Tom Lane's
points.

Tom Lane <tgl@sss.pgh.pa.us> writes:
> We want read-only access for everyone, I think, but limiting the number
> of people who can enter and update slips might be good.

I would like read-only access to the tracking database.  I am happy to
report bugs by whatever means is most efficient for the core group. 
Currently, that is the e-mail bug template, right?

> My reasons for pushing a BTS in the first place were that it would
> provide better *visibility* : has a bug been fixed, who is working
> on it, what is known about it, etc.  Basically I was thinking of a
> TODO list with more detail per item than a one-line summary.  (Also
> it should keep records of closed-out problems, so people could find
> out what version fixes a problem.)

I agree completely.

It would be nice to be able to search the bug database.  For example, it
would be useful to do a search using an error message to find out what
might be causing the problem.

> Cluttering the BTS database with random reports doesn't aid visibility
> of the important ones.  We want to allow read-only access so that status
> is visible to everyone, but that doesn't mean we have to allow everyone
> to alter the database.

Again, I agree completely.

> This line of thought also suggests that we should immediately enter
> all the TODO items into the BTS as slips... Bruce could then generate
> the text TODO via a query from the DB ;-)

Great idea.

> Further comments, anyone?

Here are my user-centric ideas on the goals for the bug tracking system:

1.  Allow end users to determine if unexpected behavior is an
outstanding bug, a bug fixed in a later release, or a feature.
2.  Cut down on 'me-too' e-mail to the mailing lists.
3.  Provide a centralized, transparent, and structured facility for
developers to report progress on bug fixes.
4.  Share work-arounds for known issues.
5.  Help users determine which release and platform to deploy.

Finally, here are my thoughts about how I would use the bug tracking
system (BTS):

1.  Before downloading and installing Postgres, check the BTS for bugs
in the release and platform I plan to deploy.
2.  If I have any problems during installation or while using Postgres,
first read the documentation, then search the BTS by keyword.
3.  If I notice any problems discussed on the mailing lists that sound
like they could affect me, check the BTS periodically to determine
whether bug is likely to be a factor.

Hope this helps.  Thank you to everybody involved in the project for
continuing to improve all aspects of PostgreSQL!

Fred Horch