Re: BugTracker (Was: Re: 8.2 features status)
От | Gregory Stark |
---|---|
Тема | Re: BugTracker (Was: Re: 8.2 features status) |
Дата | |
Msg-id | 871wrgz3f5.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: BugTracker (Was: Re: 8.2 features status) (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: BugTracker (Was: Re: 8.2 features status)
Re: BugTracker (Was: Re: 8.2 features status) Re: BugTracker (Was: Re: 8.2 features status) |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.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
В списке pgsql-hackers по дате отправления: