Re: bug database braindump from the kernel summit

[Olaf Titz]

> 1)  The idea of letting a bug "expire" is a good one.  One way to do this
> is to incorporate some form of user-base moderation into the bug
> database.  Unlike some of the forum systems, there's no reason why we can't
> have tiers of moderators:  "maintainers" are the clearinghouse people for
> certain portions of the Linux kernel source tree and should have a larger
> voice as to whether a bug is important, redundant, or completely off

As everyone thinking about this perhaps should know, this moderation
system is already used by Bugzilla: A bug report starts out as
"unconfirmed", and people who volunteer to triage bugs and are given
appropriate permission may elevate them to "new" status or resolve
them as invalid. The actual maintainers query the database only for
"new" bugs.

Experience in the Mozilla development community has shown, however,
that this is not as simple as it sounds. There are bug reports which
remain unconfirmed for weeks. People submitting reports have that
nasty feeling that they are being ignored. Really, I don't think it is
a good idea to stamp any bug report as "not to be taken seriously" by
default. It puts off people who know better.

With automatic expiry of unconfirmed reports that would be absolutely
devastating. Hopefully it is clear why. (Any pre-triaging process,
even without expiry, must be done quickly and have enough people who
do this unrewarding work, or it will introduce delays which make the
submissions increasingly worthless.)

I think that some sort of expiry is in order, but perhaps better the
other way around: any report with no progress in a certain amount of
time gets _higher_ priority, so that someone (perhaps a triager) is
"forced" to do _something_ about it (and if it's only to close an
issue which has long been fixed or is invalid from the start).

Bugzilla also does address some of the other issues presented here.
(No, I don't think it's perfect :-)

Olaf