414 lines
9.6 KiB
HTML
414 lines
9.6 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Bugzilla Configuration</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
|
"><LINK
|
|
REL="HOME"
|
|
TITLE="The Bugzilla Guide"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Administering Bugzilla"
|
|
HREF="administration.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Administering Bugzilla"
|
|
HREF="administration.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="User Administration"
|
|
HREF="useradmin.html"></HEAD
|
|
><BODY
|
|
CLASS="section"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Bugzilla Guide</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="administration.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 5. Administering Bugzilla</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="useradmin.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H1
|
|
CLASS="section"
|
|
><A
|
|
NAME="parameters"
|
|
></A
|
|
>5.1. Bugzilla Configuration</H1
|
|
><P
|
|
>Bugzilla is configured by changing various parameters, accessed
|
|
from the "Edit parameters" link in the page footer. Here are
|
|
some of the key parameters on that page. You should run down this
|
|
list and set them appropriately after installing Bugzilla.</P
|
|
><DIV
|
|
CLASS="procedure"
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
>
|
|
<B
|
|
CLASS="command"
|
|
>maintainer</B
|
|
>:
|
|
The maintainer parameter is the email address of the person
|
|
responsible for maintaining this
|
|
Bugzilla installation. The address need not be that of a valid Bugzilla
|
|
account.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>urlbase</B
|
|
>:
|
|
This parameter defines the fully qualified domain name and web
|
|
server path to your Bugzilla installation.</P
|
|
><P
|
|
>For example, if your Bugzilla query page is
|
|
<TT
|
|
CLASS="filename"
|
|
>http://www.foo.com/bugzilla/query.cgi</TT
|
|
>,
|
|
set your <SPAN
|
|
CLASS="QUOTE"
|
|
>"urlbase"</SPAN
|
|
>
|
|
to <TT
|
|
CLASS="filename"
|
|
>http://www.foo.com/bugzilla/</TT
|
|
>.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>makeproductgroups</B
|
|
>:
|
|
This dictates whether or not to automatically create groups
|
|
when new products are created.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>useentrygroupdefault</B
|
|
>:
|
|
Bugzilla products can have a group associated with them, so that
|
|
certain users can only see bugs in certain products. When this
|
|
parameter is set to <SPAN
|
|
CLASS="QUOTE"
|
|
>"on"</SPAN
|
|
>, this
|
|
causes the initial group controls on newly created products
|
|
to place all newly-created bugs in the group
|
|
having the same name as the product immediately.
|
|
After a product is initially created, the group controls
|
|
can be further adjusted without interference by
|
|
this mechanism.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>shadowdb</B
|
|
>:
|
|
You run into an interesting problem when Bugzilla reaches a
|
|
high level of continuous activity. MySQL supports only table-level
|
|
write locking. What this means is that if someone needs to make a
|
|
change to a bug, they will lock the entire table until the operation
|
|
is complete. Locking for write also blocks reads until the write is
|
|
complete. Note that more recent versions of mysql support row level
|
|
locking using different table types. These types are slower than the
|
|
standard type, and Bugzilla does not yet take advantage of features
|
|
such as transactions which would justify this speed decrease. The
|
|
Bugzilla team are, however, happy to hear about any experiences with
|
|
row level locking and Bugzilla</P
|
|
><P
|
|
>The <SPAN
|
|
CLASS="QUOTE"
|
|
>"shadowdb"</SPAN
|
|
>
|
|
parameter was designed to get around this limitation. While only a
|
|
single user is allowed to write to a table at a time, reads can
|
|
continue unimpeded on a read-only shadow copy of the database.
|
|
Although your database size will double, a shadow database can cause
|
|
an enormous performance improvement when implemented on extremely
|
|
high-traffic Bugzilla databases.</P
|
|
><P
|
|
> As a guide, mozilla.org began needing
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"shadowdb"</SPAN
|
|
>
|
|
when they reached around 40,000 Bugzilla users with several hundred
|
|
Bugzilla bug changes and comments per day.</P
|
|
><P
|
|
>The value of the parameter defines the name of the
|
|
shadow bug database. You will need to set the host and port settings
|
|
from the params page, and set up replication in your database server
|
|
so that updates reach this readonly mirror. Consult your database
|
|
documentation for more detail.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>shutdownhtml</B
|
|
>:
|
|
|
|
If you need to shut down Bugzilla to perform administration, enter
|
|
some descriptive HTML here and anyone who tries to use Bugzilla will
|
|
receive a page to that effect. Obviously, editparams.cgi will
|
|
still be accessible so you can remove the HTML and re-enable Bugzilla.
|
|
:-)
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>passwordmail</B
|
|
>:
|
|
|
|
Every time a user creates an account, the text of
|
|
this parameter (with substitutions) is sent to the new user along with
|
|
their password message.</P
|
|
><P
|
|
>Add any text you wish to the "passwordmail" parameter box. For
|
|
instance, many people choose to use this box to give a quick training
|
|
blurb about how to use Bugzilla at your site.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>movebugs</B
|
|
>:
|
|
|
|
This option is an undocumented feature to allow moving bugs
|
|
between separate Bugzilla installations. You will need to understand
|
|
the source code in order to use this feature. Please consult
|
|
<TT
|
|
CLASS="filename"
|
|
>movebugs.pl</TT
|
|
> in your Bugzilla source tree for
|
|
further documentation, such as it is.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>useqacontact</B
|
|
>:
|
|
|
|
This allows you to define an email address for each component, in
|
|
addition
|
|
to that of the default owner, who will be sent carbon copies of
|
|
incoming bugs.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>usestatuswhiteboard</B
|
|
>:
|
|
This defines whether you wish to have a free-form, overwritable field
|
|
associated with each bug. The advantage of the Status Whiteboard is
|
|
that it can be deleted or modified with ease, and provides an
|
|
easily-searchable field for indexing some bugs that have some trait
|
|
in common.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>whinedays</B
|
|
>:
|
|
Set this to the number of days you want to let bugs go
|
|
in the NEW or REOPENED state before notifying people they have
|
|
untouched new bugs. If you do not plan to use this feature, simply do
|
|
not set up the whining cron job described in the installation
|
|
instructions, or set this value to "0" (never whine).</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>commenton*</B
|
|
>:
|
|
All these
|
|
fields allow you to dictate what changes can pass without comment,
|
|
and which must have a comment from the person who changed them.
|
|
Often, administrators will allow users to add themselves to the CC
|
|
list, accept bugs, or change the Status Whiteboard without adding a
|
|
comment as to their reasons for the change, yet require that most
|
|
other changes come with an explanation.</P
|
|
><P
|
|
>Set the "commenton" options according to your site policy. It
|
|
is a wise idea to require comments when users resolve, reassign, or
|
|
reopen bugs at the very least.
|
|
<DIV
|
|
CLASS="note"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="note"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/note.gif"
|
|
HSPACE="5"
|
|
ALT="Note"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>It is generally far better to require a developer comment
|
|
when resolving bugs than not. Few things are more annoying to bug
|
|
database users than having a developer mark a bug "fixed" without
|
|
any comment as to what the fix was (or even that it was truly
|
|
fixed!)</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>supportwatchers</B
|
|
>:
|
|
|
|
Turning on this option allows users to ask to receive copies of
|
|
all a particular other user's bug email. This is, of
|
|
course, subject to the groupset restrictions on the bug; if the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"watcher"</SPAN
|
|
>
|
|
would not normally be allowed to view a bug, the watcher cannot get
|
|
around the system by setting herself up to watch the bugs of someone
|
|
with bugs outside her privileges. They would still only receive email
|
|
updates for those bugs she could normally view.</P
|
|
></LI
|
|
></OL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="administration.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="useradmin.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Administering Bugzilla</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="administration.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>User Administration</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |