<primary>checklist</primary>
</indexterm>
- <procedure>
- <step>
- <para>
- <command>maintainer</command>:
-
- 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.
- </para>
- </step>
-
- <step>
- <para>
- <command>urlbase</command>:
-
- This parameter defines the fully qualified domain name and web
- server path to your Bugzilla installation.
- </para>
-
- <para>
- For example, if your Bugzilla query page is
- <filename>http://www.foo.com/bugzilla/query.cgi</filename>,
- set your <quote>urlbase</quote>
- to <filename>http://www.foo.com/bugzilla/</filename>.
- </para>
- </step>
-
- <step>
- <para>
- <command>usebuggroups</command>:
-
- This dictates whether or not to implement group-based security for
- Bugzilla. If set, Bugzilla bugs can have an associated 'group',
- defining which users are allowed to see and edit the
- bug.
- </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ maintainer
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
+ </listitem>
+ </varlistentry>
- <para>
- Set <quote>usebuggroups</quote> to <quote>on</quote>
- <emphasis>only</emphasis> if you may wish to restrict access
- to particular bugs to certain groups of users. I suggest leaving
- this parameter <emphasis>off</emphasis>
- while initially testing your Bugzilla.
- </para>
+ <varlistentry>
+ <term>
+ urlbase
+ </term>
+ <listitem>
+ <para>
+ This parameter defines the fully qualified domain name and web
+ server path to your Bugzilla installation.
+ </para>
- <para>
- For more information see <xref linkend="groups"/>.
- </para>
- </step>
+ <para>
+ For example, if your Bugzilla query page is
+ <filename>http://www.foo.com/bugzilla/query.cgi</filename>,
+ set your <quote>urlbase</quote>
+ to <filename>http://www.foo.com/bugzilla/</filename>.
+ </para>
+ </listitem>
+ </varlistentry>
- <step>
- <para>
- <command>usebuggroupsentry</command>:
+ <varlistentry>
+ <term>
+ usebuggroups
+ </term>
+ <listitem>
+ <para>
+ This dictates whether or not to implement group-based security for
+ Bugzilla. If set, Bugzilla bugs can have an associated 'group',
+ defining which users are allowed to see and edit the
+ bug.
+ </para>
- 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 <quote>on</quote>, this places all
- newly-created bugs in the group for their product immediately.
- </para>
- </step>
+ <para>
+ Set <quote>usebuggroups</quote> to <quote>on</quote>
+ <emphasis>only</emphasis> if you may wish to restrict access
+ to particular bugs to certain groups of users. I suggest leaving
+ this parameter <emphasis>off</emphasis>
+ while initially testing your Bugzilla.
+ </para>
- <step>
- <para>
- <command>shadowdb</command>:
-
- 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.
- </para>
+ <para>
+ For more information see <xref linkend="groups"/>.
+ </para>
+ </listitem>
+ </varlistentry>
- <para>
- The <quote>shadowdb</quote> 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.
- </para>
-
- <para>
- As a guide, on reasonably old hardware, mozilla.org began needing
- <quote>shadowdb</quote> when they reached around 40,000 Bugzilla
- users with several hundred Bugzilla bug changes and comments per day.
- </para>
+ <varlistentry>
+ <term>
+ usebuggroupsentry
+ </term>
+ <listitem>
+ <para>
+ 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 <quote>on</quote>, this places all
+ newly-created bugs in the group for their product immediately.
+ </para>
+ </listitem>
+ </varlistentry>
- <para>
- The value of the parameter defines the name of the shadow bug
- database. Set "shadowdb" to e.g. "bug_shadowdb" if you will be
- running a *very* large installation of Bugzilla.
- </para>
+ <varlistentry>
+ <term>
+ shadowdb
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
- <note>
<para>
- Enabling "shadowdb" can adversely affect the stability of your
- installation of Bugzilla. You should regularly check that your
- database is in sync. It is often advisable to force a shadow
- database sync nightly via <quote>cron</quote>.
+ The <quote>shadowdb</quote> 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.
</para>
- </note>
- <para>
- If you use the <quote>shadowdb</quote> option, it is only natural
- that you should turn the <quote>queryagainstshadowdb</quote>
- option on as well. Otherwise you are replicating data into a shadow
- database for no reason!
- </para>
- </step>
-
- <step>
- <para>
- <command>shutdownhtml</command>:
-
- If you need to shut down Bugzilla to perform administration, enter
- some descriptive text (with embedded HTML codes, if you'd like)
- into this box. Anyone who tries to use Bugzilla (including admins)
- will receive a page displaying this text. Users can neither log in
- nor log out while shutdownhtml is enabled.
- </para>
-
- <note>
<para>
- Although regular log-in capability is disabled while 'shutdownhtml'
- is enabled, safeguards are in place to protect the unfortunate
- admin who loses connection to Bugzilla. Should this happen to you,
- go directly to the <filename>editparams.cgi</filename> (by typing
- the URL in manually, if necessary). Doing this will prompt you to
- log in, and your name/password will be accepted here (but nowhere
- else).
+ As a guide, on reasonably old hardware, mozilla.org began needing
+ <quote>shadowdb</quote> when they reached around 40,000 Bugzilla
+ users with several hundred Bugzilla bug changes and comments per day.
</para>
- </note>
- </step>
- <step>
- <para>
- <command>passwordmail</command>:
+ <para>
+ The value of the parameter defines the name of the shadow bug
+ database. Set "shadowdb" to e.g. "bug_shadowdb" if you will be
+ running a *very* large installation of Bugzilla.
+ </para>
- 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.
- </para>
+ <note>
+ <para>
+ Enabling "shadowdb" can adversely affect the stability of your
+ installation of Bugzilla. You should regularly check that your
+ database is in sync. It is often advisable to force a shadow
+ database sync nightly via <quote>cron</quote>.
+ </para>
+ </note>
+
+ <para>
+ If you use the <quote>shadowdb</quote> option, it is only natural
+ that you should turn the <quote>queryagainstshadowdb</quote>
+ option on as well. Otherwise you are replicating data into a shadow
+ database for no reason!
+ </para>
+ </listitem>
+ </varlistentry>
- <para>
- 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.
- </para>
- </step>
+ <varlistentry>
+ <term>
+ shutdownhtml
+ </term>
+ <listitem>
+ <para>
+ If you need to shut down Bugzilla to perform administration, enter
+ some descriptive text (with embedded HTML codes, if you'd like)
+ into this box. Anyone who tries to use Bugzilla (including admins)
+ will receive a page displaying this text. Users can neither log in
+ nor log out while shutdownhtml is enabled.
+ </para>
- <step>
- <para>
- <command>movebugs</command>:
+ <note>
+ <para>
+ Although regular log-in capability is disabled while 'shutdownhtml'
+ is enabled, safeguards are in place to protect the unfortunate
+ admin who loses connection to Bugzilla. Should this happen to you,
+ go directly to the <filename>editparams.cgi</filename> (by typing
+ the URL in manually, if necessary). Doing this will prompt you to
+ log in, and your name/password will be accepted here (but nowhere
+ else).
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
- 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
- <filename>movebugs.pl</filename> in your Bugzilla source tree for
- further documentation, such as it is.
- </para>
- </step>
+ <varlistentry>
+ <term>
+ passwordmail
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
- <step>
- <para>
- <command>useqacontact</command>:
+ <para>
+ 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.
+ </para>
+ </listitem>
+ </varlistentry>
- 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.
- </para>
- </step>
+ <varlistentry>
+ <term>
+ movebugs
+ </term>
+ <listitem>
+ <para>
+ 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
+ <filename>movebugs.pl</filename> in your Bugzilla source tree for
+ further documentation, such as it is.
+ </para>
+ </listitem>
+ </varlistentry>
- <step>
- <para>
- <command>usestatuswhiteboard</command>:
+ <varlistentry>
+ <term>
+ useqacontact
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
+ </listitem>
+ </varlistentry>
- 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.
- </para>
- </step>
+ <varlistentry>
+ <term>
+ usestatuswhiteboard
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
+ </listitem>
+ </varlistentry>
- <step>
- <para>
- <command>whinedays</command>:
+ <varlistentry>
+ <term>
+ whinedays
+ </term>
+ <listitem>
+ <para>
+ 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).
+ </para>
+ </listitem>
+ </varlistentry>
- 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).
- </para>
- </step>
+ <varlistentry>
+ <term>
+ commenton*
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
- <step>
- <para>
- <command>commenton*</command>:
-
- 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.
- </para>
+ <para>
+ 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.
+ </para>
- <para>
- 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.
- </para>
+ <note>
+ <para>
+ 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!)
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
- <note>
+ <varlistentry>
+ <term>
+ supportwatchers
+ </term>
+ <listitem>
<para>
- 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!)
+ Turning on this option allows users to ask to receive copies
+ of bug mail sent to another user. Watching a user with
+ different group permissions is not a way to 'get around' the
+ system; copied emails are still subject to the normal groupset
+ permissions of a bug, and <quote>watchers</quote> will only be
+ copied on emails from bugs they would normally be allowed to view.
</para>
- </note>
- </step>
-
- <step>
- <para>
- <command>supportwatchers</command>:
-
- Turning on this option allows users to ask to receive copies
- of bug mail sent to another user. Watching a user with
- different group permissions is not a way to 'get around' the
- system; copied emails are still subject to the normal groupset
- permissions of a bug, and <quote>watchers</quote> will only be
- copied on emails from bugs they would normally be allowed to view.
- </para>
- </step>
- </procedure>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</section>
<section id="useradmin">
projects / thirdparty / bugzilla.git / commitdiff
