Re: BugTracker (Was: Re: 8.2 features status)
От | Andrew Dunstan |
---|---|
Тема | Re: BugTracker (Was: Re: 8.2 features status) |
Дата | |
Msg-id | 44E31A47.701@dunslane.net обсуждение исходный текст |
Ответ на | Re: BugTracker (Was: Re: 8.2 features status) (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
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 |
Martijn van Oosterhout wrote: > On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote: > >> Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat: >> >>> I'm not sure I follow this, since currently anyone can email the bugs list >>> or use the bugs -> email form from the website. Are you looking to >>> increase the barrier for bug reporting? >>> >> Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most >> are confused or misdirected users. I don't want to raise that barrier. But >> I want a higher barrier before something is recorded in the bug tracking >> system. >> > > Well, you need to get some agreement on what the bug tracker is for. Is > it: > > a) a front-end to deal with complaints and bugs people have. Is it > something you expect end users to look at? This is how Debian uses its > bug-tracker, to make sure issues people bring up don't get lost. You > can always close the bug if it isn't a real bug. > > Or: > > b) a private bug database only used by -hackers to track known > outstanding bugs and patches. > > If you want the latter, the approach would be to keep pgsql-bugs and > when a real issue comes up, bounce it to the bug tracker. Any > subsequent email discussion should then get logged in the bug report. > > Have a nice day, > What we are talking about here is bug triage. Weeding out misreports, duplicates etc. is a prime part of this function. It is essential to the health of any functioning bug tracking system. All it takes is resources. Is it worth it? Yes, IMNSHO, but it's a judgement call. One sensible way to do this would be to have a group of suitably qualified volunteers who could perform this function on a roster basis, for, say, a week or a two at a time. That way we could the load off key personnel like Tom (I am in favor of anything which would reduce the demands we place on Tom ;-) ) cheers andrew
В списке pgsql-hackers по дате отправления: