Bug tracking system policy
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
(btw, I've taken this on-list per Tom Lane's suggestion; the
short summary is that the new bug tracking system is getting non-bug
bug reports and it is short-circuiting the highly successful mailing
list support process.)
Just to give everyone else some context (and try to get a more useful
title on the thread ;-)), this discussion concerns the Keystone bug
tracking system that was recently installed on www.postgresql.org;
see http://www.PostgreSQL.ORG/bugs/nbrowse.php3. There is some
sketchy documentation about Keystone at
http://www.stonekeep.com/ksonline/docs/docindex.html.
Now that we've got the thing, we need to figure out an effective process
for using it. The limited experience so far doesn't seem particularly
productive. Here are some comments that I sent to the core group
earlier today.
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
We've got a *great* network of folks on the mailing lists who help
everyone with questions. That should be the first (and second, and
third) line of defense for anyone with a question or a possible bug
report, and imho we shouldn't have *anything* in the bug tracking
system which has not gone through that process first.
How do we accomplish this without having a completely closed bug
reporting system (which for me is one of the options; Bruce could use
this for his bug-related ToDo's...).
Hmm, so you are thinking it should be a *tracking* system for
acknowledged bugs, but not an initial reporting system, and we'd
continue to rely on the mail lists for initial reporting.
That might not be a bad idea. I've already noticed that people
are failing to provide full bug reports (version, platform, etc)
because the Keystone system doesn't give them a template to fill out.
Seems like we were getting more complete reports via the email process.
Should we consider having a more limited number of folks with access
to the bug tracking system? Perhaps this could be a perk for long-time
contributors who go out of their way to help answer questions??
We want read-only access for everyone, I think, but limiting the number
of people who can enter and update slips might be good.
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.)
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.
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 ;-)
Further comments, anyone?
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue27Jul1999165255+0000379DE3E7.F8F2B951@alumni.caltech.edu
I wrote:
Er, make that
http://www.PostgreSQL.ORG/bugs/visitor.php3
if you're not one of the people known to the Keystone system...
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue27Jul1999131134-04007736.933095494@sss.pgh.pa.us | Resolved by subject fallback
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
Import Notes
Resolved by subject fallback
Just a thought, but we know *what* we want...why not build our own? Or,
is there something else out there that would better serve what we need?
Personally, my playing with Keystone leaves much to be desired, and the
mailing list for it, quite frankly, is totally unresponsive. (ie. no
questions asked have turned up an answer)...if someone has something
better they would like to suggest, I have no problems setting it up and
running through it.
If someone thinks they have the time, energy and desire to work on one
from scratch, tailoring it to our requirements, let me know that
also...I'll provide you with an account and the resources...
The idea is to come up with something clean, easy to use and fully
functional...something that ppl *will* use. I don't think Keystone is
that, but I haven't seen anything closer/better to what we require...
On Tue, 27 Jul 1999, Tom Lane wrote:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
(btw, I've taken this on-list per Tom Lane's suggestion; the
short summary is that the new bug tracking system is getting non-bug
bug reports and it is short-circuiting the highly successful mailing
list support process.)Just to give everyone else some context (and try to get a more useful
title on the thread ;-)), this discussion concerns the Keystone bug
tracking system that was recently installed on www.postgresql.org;
see http://www.PostgreSQL.ORG/bugs/nbrowse.php3. There is some
sketchy documentation about Keystone at
http://www.stonekeep.com/ksonline/docs/docindex.html.Now that we've got the thing, we need to figure out an effective process
for using it. The limited experience so far doesn't seem particularly
productive. Here are some comments that I sent to the core group
earlier today.Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
We've got a *great* network of folks on the mailing lists who help
everyone with questions. That should be the first (and second, and
third) line of defense for anyone with a question or a possible bug
report, and imho we shouldn't have *anything* in the bug tracking
system which has not gone through that process first.How do we accomplish this without having a completely closed bug
reporting system (which for me is one of the options; Bruce could use
this for his bug-related ToDo's...).Hmm, so you are thinking it should be a *tracking* system for
acknowledged bugs, but not an initial reporting system, and we'd
continue to rely on the mail lists for initial reporting.That might not be a bad idea. I've already noticed that people
are failing to provide full bug reports (version, platform, etc)
because the Keystone system doesn't give them a template to fill out.
Seems like we were getting more complete reports via the email process.Should we consider having a more limited number of folks with access
to the bug tracking system? Perhaps this could be a perk for long-time
contributors who go out of their way to help answer questions??We want read-only access for everyone, I think, but limiting the number
of people who can enter and update slips might be good.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.)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.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 ;-)Further comments, anyone?
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Just a thought, but we know *what* we want...why not build our own? Or,
is there something else out there that would better serve what we need?Personally, my playing with Keystone leaves much to be desired, and the
mailing list for it, quite frankly, is totally unresponsive. (ie. no
questions asked have turned up an answer)...if someone has something
better they would like to suggest, I have no problems setting it up and
running through it.
They obviously need better bug tracking software. :-)
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026On Tue, 27 Jul 1999, Bruce Momjian wrote:
Just a thought, but we know *what* we want...why not build our own? Or,
is there something else out there that would better serve what we need?Personally, my playing with Keystone leaves much to be desired, and the
mailing list for it, quite frankly, is totally unresponsive. (ie. no
questions asked have turned up an answer)...if someone has something
better they would like to suggest, I have no problems setting it up and
running through it.They obviously need better bug tracking software. :-)
*grin*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org