Re: Bugzilla for GNOME (was Re: GNOME CVS: nautilus mathieu)
- From: Mark Gordon <mtgordon helixcode com>
- To: Martin Baulig <martin home-of-linux org>
- Cc: gnome-private gnome org
- Subject: Re: Bugzilla for GNOME (was Re: GNOME CVS: nautilus mathieu)
- Date: 28 Oct 2000 00:54:00 +0500
Martin wrote:
> Basically, it doesn't matter which trasportation medium bug-buddy will
> use, but there should be some checks on the server side:
Some of this is better suited to client-side validation, which provides faster
turnaround.
> * silently drop all bug reports originating from non-existant email
> addresses (root localhost localdomain).
Prompting the user for a real address should be sufficient.
> * 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.
Prompting the user for a subject should be sufficient. I can see this happening by
oversight.
> * silently drop all bug reports containing less than 10 words with or
> without stack trace.
This does seem a bit more reasonable.
> * 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.
"gHello-world crashed on launch", with stack trace and version info, is about all the
user can provide in some cases.
> * 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.
I was trained to write bug reports that were complete but succinct. If I have a bug
isolated to a minimal case, it's quite common for it to take less than 100 words.
> * 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.
This is the only one so far that it ought to be run on the server. At the same time,
we should make sure to treat this diplomatically. I've seen plenty of redundant bug
reports, the last of which includes a patch. Let's not discourage that last
redundant bug report! :-)
-Mark Gordon
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]