After installation, follow the checklist below to ensure that + you have a successful installation. + If you do not see a recommended setting for a parameter, + consider leaving it at the default + while you perform your initial tests on your Bugzilla setup. +
Set "maintainer" to your email address. + This allows Bugzilla's error messages + to display your email + address and allow people to contact you for help. +
Set "urlbase" to the URL reference for your Bugzilla installation. + If your bugzilla query page is at http://www.foo.com/bugzilla/query.cgi, + your url base is http://www.foo.com/bugzilla/ +
Set "usebuggroups" to "1" only + if you need to restrict access to products. + I suggest leaving this parameter off + while initially testing your Bugzilla. +
Set "usebuggroupsentry" to "1" if you want to be able to restrict access to products. + Once again, if you are simply testing your installation, I suggest against + turning this parameter on; the strict security checking may stop you from + being able to modify your new entries. +
Set "shadowdb" to "bug_shadowdb" if you will be + running a *very* large installation of Bugzilla. + The shadow database enables many simultaneous users + to read and write to the database + without interfering with one another. +
Note: Enabling "shadowdb" can adversely affect the stability + of your installation of Bugzilla. + You may frequently need to manually synchronize your databases, + or schedule nightly syncs + via "cron" +
If you use the "shadowdb" option, it is only natural that you should turn the "queryagainstshadowdb" + option "On" as well. Otherwise you are replicating data into a shadow database for no reason! +
If you have custom logos or HTML you must put in place to fit within your site design guidelines, + place the code in the "headerhtml", "footerhtml", "errorhtml", "bannerhtml", or "blurbhtml" text boxes. +
Note: The "headerhtml" text box is the HTML printed out before any other code on the page. + If you have a special banner, put the code for it in "bannerhtml". You may want to leave these + settings at the defaults initially. +
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. +
Set "newemailtech" to "on". Your users will thank you. This is the default in the post-2.12 world. +
Do you want to use the qa contact ("useqacontact") and status whiteboard ("usestatuswhiteboard") fields? + These fields are useful because they allow for more flexibility, particularly when you have an existing + Quality Assurance and/or Release Engineering team, + but they may not be needed for smaller installations. +
Set "whinedays" to the amount 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 README, or set this value to "0". +
Set the "commenton" options according to your site policy. It is a wise idea to require comments when users + resolve, reassign, or reopen bugs. +
Note: 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!) +
Set "supportwatchers" to "On". This feature is helpful for team leads to monitor progress in their + respective areas, and can offer many other benefits, such as allowing a developer to pick up a + former engineer's bugs without requiring her to change all the information in the bug. +