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