Re: BugTracker (Was: Re: 8.2 features status)

From: Gregory Stark <gsstark(at)mit(dot)edu>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Kenneth Marshall <ktm(at)is(dot)rice(dot)edu>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: BugTracker (Was: Re: 8.2 features status)
Date: 2006-08-16 23:06:22
Message-ID: 871wrgz3f5.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:

> What we are talking about here is bug triage.

Really? We have a problem with too many bug reports and need a tool to help
triage them? That's the first I've heard of that.

Think about what tasks you do now and what tool would make it easier. Don't
try to invent problems to solve.

The Debian system would be basically zero operational change. pgsql-bugs would
continue to exist exactly as it does now except it would go through debbugs.
Any message there would open a bug report. Anyone responding to say "that's
not a bug" would just include the magic phrase to close the bug report too.

Anyone responding with questions or data would just respond as normal. The net
result would be exactly as it is now except that there would be a tool to view
what bugs are still open and look at all the data accumulated on that bug. And
you could look back at old bugs to see what version they were fixed in and
what the bug looked like to see if it matched the problem a user is having.

In short, it's just a tool to solve a problem we actually have (having a
convenient archive of data about current and past bugs) without inventing
problems to solve with extra process that we aren't already doing anyways.

RT can be set up similarly but I'm not sure how much work it would take to
make it as seamless. Debbugs has the advantage of working that way pretty much
out of the box.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2006-08-16 23:21:06 Re: Enum proposal / design
Previous Message Jim C. Nasby 2006-08-16 23:02:30 Re: An Idea for planner hints