FWIW, I agree with Thomas' comments: our last try at a bug-tracking
system was a spectacular failure, and rather than just trying again
with a technically better bug-tracker, we need to understand why we
failed before.
I think we do need to look for a better answer than what we have, but
I do not have any faith in "install system FOO and all your problems
will be solved".
My take is that
(a) a bug *tracking* system is not the same as a bug *reporting*
system. A tracking system will be useless if it gets cluttered
with non-bug reports, duplicate entries, etc. There must be a human
filter controlling what gets entered into the system.
(b) our previous try (with Keystone) was a failure in part because
it was not even effective as a bug reporting system: it did not
encourage people to fill in our standard "bug report form", with the
result that bug reports were seriously incomplete w.r.t. version
numbers, platforms, etc. This is a relatively simple technical
deficiency, not a social-engineering problem, but it does point up
the fact that one-size-fits-all solutions fit nobody.
(c) fill-in-the-web-form reporting systems suck. They make it
difficult to copy-and-paste query output, dump files, etc.
Also, the window for entering text is always either too small or too
large. Email with attachments is fundamentally superior.
(d) divorcing the bug reporting system from the existing mailing
list community is foolish, as Thomas pointed out. When a bug report
is a non-bug (user error, etc) or fixed in a later version or just
a duplicate, we tend to rely on the rest of the community to give
the reporter a helpful response. Funneling reports into a separate
system that is only read by a few key developers will lose.
I'm not sure what I want, but I know what I don't want...
regards, tom lane