From: | Vince Vielhaber <vev(at)michvhf(dot)com> |
---|---|
To: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | bugs - lets call an exterminator! |
Date: | 2001-08-22 00:08:19 |
Message-ID: | Pine.BSF.4.30.0108211821330.51535-100000@paprika.michvhf.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 input
o Minimal staff involvement
o Maximal mailing list reporting
o History
o 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(at)michvhf(dot)com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From | Date | Subject | |
---|---|---|---|
Next Message | Ned Wolpert | 2001-08-22 00:36:02 | Re: JDBC changes for 7.2... some questions... |
Previous Message | Matthew T. O'Connor | 2001-08-22 00:08:13 | Re: Link to bug webpage |