Introduction

The project uses the bug database program Bugzilla (general info on bugzilla can be found at www.bugzilla.org. Our bug database is installed at the HUM-fak web server, here:

Following this link brings you to our bug database. It is easier to use via a graphical web browser (Safari, Netscape) than via lynx, although you may use it with lynx as well.

If you don't have access to it yet, go to the url in question (with a graphical browser), and log in. Bugzilla will ask four your email address as user name, and mail you a password (which you may change later on). Then there is a

I copied it from the Bugzilla pages, so that we could get easy access to our version of Bugzilla (which is 2.16.6). Large parts of it is for maintainers, but there are chapters there for end users as well. Have a look at it before you ask for help (eager readers will find a pdf version of the guide here).

Informal rules of thumb for using Bugzilla

  1. If you find a bug, see if you can fix it yourself, at once.
  2. If you cannot fix it, or you cannot fix it just now, go to Bugzilla
  3. Check that the bug is not already reported, and
  4. report the bug.

And remember that the project also has a news group server, at news.uit.no. Principled questions and errors without clear answers should be discussed there (you may of course both report a bug in bugzilla and open a discussion in the news group if you find that appropriate).



A bug database discussion from 2001

(The text below is from 2001, when we first planned to get a bug database. I leave it here for reference (041013 , Trond), let us delete it when the documentation of the working Bugzilla system is in place.)

The text here is just to exchange notes on how the bug database should be organised. Seperate files will be written as soon as we know what to write.

How to store error reports

I take it that they must be stored in two ways, a. web-accessible and b. via e-mail to the project coworkers. it would have been nice to have access to the database from lynx as well, so I hope Bugzilla has a lynx-friendly output.

Error categories

Two scroll bars with these options, and the first member of each as the default choice.

One category for language:

One category for error type (and with a text to explain the categories):

One category for platform:

One category for seriousness

One category for status

Perhaps as in the Bugzilla standard edition:

Rules for notification should be simple: They should be distributed according to language, and to +/- technical.

I don't see any relevance in the bug changes category.


Last modified: Wed Oct 13 14:31:09 2004