bugs - lets call an exterminator!
От | Vince Vielhaber |
---|---|
Тема | bugs - lets call an exterminator! |
Дата | |
Msg-id | Pine.BSF.4.30.0108211821330.51535-100000@paprika.michvhf.com обсуждение исходный текст |
Ответы |
Re: bugs - lets call an exterminator!
(teg@redhat.com (Trond Eivind Glomsrød))
Re: bugs - lets call an exterminator! ("D. Hageman" <dhageman@dracken.com>) Re: bugs - lets call an exterminator! (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
In the seemingly hundreds of thousands of messages on the bug database topic I think I've come up with the following.. Needs ----------------------------------------------------------------------- easy reporting of bugs - sent to bugs list easy lookup of previous bugs summary of fix or workaround detail of fix or work around little to no intervention of developers ability of developer to add comments That should sum it up. Now some history.. Over the last couple of years we've tried a number (5 I think) of bug tracking packages. Either Marc or me or both have had to learn it, install it, get it going and the result has been the same - the maintainers don't want to update it, it's a pain in the ass to administrator, set up, etc. The current bugtool. After a bunch of these failures I asked for input on what was needed in a tool. Web input interface, ability to track the bug report, email notification to the bug list, email notification to the reporter of the bug. The current bugtool does this, however the maintainers don't want to close the reports. I'm not faulting them, they're doing their jobs by fixing the bugs and reporting them to the bugs list. Updating the database. We've had a couple of volunteers to keep the database up to date. Is it enough? I dunno, if I were to guess I'd have to look at previous experience and say probably not. But I don't want that to discourage anything or anyone. Realities PostgreSQL is growing by leaps and bounds. Ross pointed out this fact earlier today. A solution has to happen and it has to happen now. If a tool is to be adapted to this task it will be the one I'm most familiar with - the current one. Solution.. Is implementing yet another bugtool going to be the solution? Probably not. Do I want to go for number six? No. Of the ideas posted, these stick out: o Web inputo Minimal staff involvemento Maximal mailing list reportingo Historyo Searchability Here's what I propose. The current tool has a form - we keep it. The current tool mails to the bugs list - we keep it. Rather than searching the bugs list for open bugs that may not even be open, the search tool will need to search not only the database but it needs to also search the archives. For now (until the 400+ are classified) the search should/will search the bugs mailing list rather than the database. Recruit more than two people to help update the bugs database. After the database is somewhat up to date, include it into the normal search mechanism. Now then.. The folks that actually fix things, will this suffice as a start to our shortcomingss? If not, what is missing?? If so, let me know and I'll implement this in the short term. Silence at this time is definitely NOT A GOOD THING!!! Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
В списке pgsql-hackers по дате отправления: