summaryrefslogtreecommitdiffstats
path: root/docs/html/parameters.html
diff options
context:
space:
mode:
authorjustdave%syndicomm.com <>2004-02-05 13:49:08 +0100
committerjustdave%syndicomm.com <>2004-02-05 13:49:08 +0100
commit11945a73c631bedbcf8daaba531964c3fc2d6333 (patch)
tree6c23288dd801bd8a1bf9ad548eb9a4e82cd24eef /docs/html/parameters.html
parentcfc778d1fc757e022c0755ccc5ecd430790ce8be (diff)
downloadbugzilla-11945a73c631bedbcf8daaba531964c3fc2d6333.tar.gz
bugzilla-11945a73c631bedbcf8daaba531964c3fc2d6333.tar.xz
- Remove html, txt, and pdf directories from CVS
- makedocs.pl now creates said directories when building the docs The idea here is that it's useless to have compiled stuff in CVS. The website will now auto-build the docs upon changes to the xml directory.
Diffstat (limited to 'docs/html/parameters.html')
-rw-r--r--docs/html/parameters.html416
1 files changed, 0 insertions, 416 deletions
diff --git a/docs/html/parameters.html b/docs/html/parameters.html
deleted file mode 100644
index 8212e4c18..000000000
--- a/docs/html/parameters.html
+++ /dev/null
@@ -1,416 +0,0 @@
-<HTML
-><HEAD
-><TITLE
->Bugzilla Configuration</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
-"><LINK
-REL="HOME"
-TITLE="The Bugzilla Guide - 2.17.7
- Development Release"
-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 - 2.17.7
- Development Release</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 3. 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
->3.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
->&#13; <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
->&#13; <B
-CLASS="command"
->makeproductgroups</B
->:
- This dictates whether or not to automatically create groups
- when new products are created.
- </P
-></LI
-><LI
-><P
->&#13; <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
->&#13; <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
->&#13; As a guide, on reasonably old hardware, 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
->&#13; <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
->&#13; <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
->&#13; <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
->&#13; <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
->&#13; <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
->&#13; <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
->&#13; <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
->&#13; <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
-> \ No newline at end of file