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

[Maciej Stachowiak <mjs eazel com>]

Martin Baulig <martin home-of-linux org> writes:

> 
> 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.
> 

Dropping the old bugs on the floor is simply not acceptable. I'm
shocked that you would suggest it at all since you are usually so
sensible. :-) If there are low quality bug reports in there, then
bugzilla makes it very easy to mark large batch groupings of them
INVALID.

> 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.

We should presume the bug reports are good, and let the maintainers
close the ones that aren't once over in 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.

For Nautilus and other projects maintained by people at Eazel, we tell
people to go ahead and file a bug if they're in doubt as to whether
it's a duplicate; we're willing to suffer a few duplicates to avoid
missing valueable bug reports. And bugzilla makes it really easy to
close duplicates.

So this is not a huge worry. I think having a mail gateway is pretty
necessary, a lot of users with slow, or metered, or not always on
connections have said this is a must for them, and some of these users
are among our best bug reporters. I'm not sure if making the gateway
emulate debbugs is necessary or sensible; I guess that's the easiest
way to be compatible with all the bug-buddies out there, but I don't
think debbugs matches up with the fields in a bugzilla bug report very
well.

> 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:

What you describe below sounds really cool though, as far as bug-buddy
improvement suggestions.

> * 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.


But I'm not sure I like the ideas below:

> 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).

I'd put these in but make it OK by policy to close them out if they
can't be solved without more info.
 
> * 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.

Disagree, sometimes four words really is enough to describe the bug,
or even if there is a lame subject but the body is good, bugzilla
makes it easy to change the subject to something better.

> * 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.

Numeric limits on the number of words is a silly way to do it. It's
not hard to ask the reporter for more info manually, or mark the bug
INVALID if it's so uninformative as to be totally unuseful.
 
> * 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.

Again, disagreed. A human should make the determination of duplicates,
not a program. Determining if a bug is really a duplicate or not is
subtle.

Really, we're not going to be able to write a program to truly tell
good bug reports from bad except for really extreme cases. Bugzilla
makes it really easy to manipulate bug reports and even do batch
closings, so let's see how that works out before we try putting more
hostility in the bug reporting process.

 - Maciej