Re: Bugzilla for GNOME (was Re: GNOME CVS: nautilus mathieu)

[Martin Baulig <martin home-of-linux org>]

Alan Cox <alan redhat com> writes:

> > > whether to drop all of them on the floor.
> > 
> > I am willing to volunteer some time to move bugs over (that way we can
> > "filter" out the high quality bug reports from the crap ones).
> 
> if you have a mail filter working you dont need to waste people time on this,
> you just fire all the bugs through the bug wrapper

Well, I think the best way to do this is to give the maintainers of each
module one or two weeks to look over the bugs in the old bug tracker and
then just dump it to the ground.

Most stuff in the old bug tracker is crap anyways which we don't want to
have in Bugzilla, so we just need to keep the old bugtracker running for
one or two weeks (while it is already rejecting all new bug reports) to
give the maintainers some time to find the really good bugs and resubmit
them to Bugzilla.

Also, I think having an email gateway to Bugzilla is a bad idea and just
using a debbugs wrapper for it is even worse. Reporting a bug is nothing
you can do by simply sending an email. For instance, you normally need to
look in the database whether the bug has already been reported.

What we really need is to add a Bugzilla interface to bug-buddy with
off-line bug-reporting support. I think the best way to do this is the
following:

* Create an xml file on the server with Bugzilla's Products, Components,
  Keywords etc. in it which is periodically updated from the database.

  Ship this xml file with bug-buddy but let bug-buddy connect to the
  server (ask the user first) and update the file; this file should also
  contain additional information such as:

  - the latest required bug-buddy version (and bug-buddy should refuse to
    report any bugs if it is older)
  - additional maintainer-settable policies

* Add a way to browse the bug database and search for bugs in bug-buddy
  (maybe this can be done with a link which you can open in Netscape).

* Add a FRB (Frequently Reported Bugs) database and let bug-buddy either
  use the online version or an offline copy.

* Enhance bug-buddy's user interface to tell people how write good bug
  reports etc.

Basically, it doesn't matter which trasportation medium bug-buddy will
use, but there should be some checks on the server side:

* silently drop all bug reports originating from non-existant email
  addresses (root localhost localdomain).

* silently drop all bug reports without a subject, with a subject which
  is shorter than 5 words or with a subject which matches some regex.

* silently drop all bug reports containing less than 10 words with or
  without stack trace.

* reject all bug reports containing less than 50 words if they contain a
  valid stack trace, send a mail back and ask people to resubmit.

* reject all bug reports containing less than 100 words if they don't
  contain a valid stack trace, send a mail back and ask people to
  resubmit.

* reject all bug reports which are in the FRB list (which should also
  contain a set of regexp's), send a mail back and ask people to check the
  online database whether the bug is really different and let them submit
  it directly in Bugzilla.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)