Appendix A. The Bugzilla FAQ

You can stay up-to-date with the latest Bugzilla information at http://www.mozilla.org/projects/bugzilla/

Bugzilla is covered by the Mozilla Public License. See details at http://www.mozilla.org/MPL/

www.collab.net offers Bugzilla as part of their standard offering to large projects. They do have some minimum fees that are pretty hefty, and generally aren't interested in small projects.

There are several experienced Bugzilla hackers on the mailing list/newsgroup who are willing to whore themselves out for generous compensation. Try sending a message to the mailing list asking for a volunteer.

There are dozens of major comapanies with public Bugzilla sites to track bugs in their products. A few include:

Bugzilla maintenance has been in a state of flux recently. Please check the Bugzilla Project Page for the latest details.

A year has gone by, and I still can't find any head-to-head comparisons of Bugzilla against other defect-tracking software. However, from my personal experience with other bug-trackers, Bugzilla offers superior performance on commodity hardware, better price (free!), more developer- friendly features (such as stored queries, email integration, and platform independence), improved scalability, open source code, greater flexibility, and superior ease-of-use.

If you happen to be a commercial bug-tracker vendor, please step forward with a rebuttal so I can include it in the FAQ. We're not in pursuit of Bugzilla ueber alles; we simply love having a powerful, open-source tool to get our jobs done.

You can't. However, the administrative account can, by simply opening your user account in editusers.cgi and changing the login name.

It may be that the support has not been built yet, or that you have not yet found it. Bugzilla is making tremendous strides in usability, customizability, scalability, and user interface. It is widely considered the most complete and popular open-source bug-tracking software in existence.

That doesn't mean it can't use improvement! You can help the project along by either hacking a patch yourself that supports the functionality you require, or else submitting a "Request for Enhancement" (RFE) using the bug submission interface at bugzilla.mozilla.org.

Terry Weissman answers,

You're not the only one. But I am not very interested. I'm not a real SQL or database person. I just wanted to make a useful tool, and build it on top of free software. So, I picked MySQL, and learned SQL by staring at the MySQL manual and some code lying around here, and wrote Bugzilla. I didn't know that Enum's were non-standard SQL. I'm not sure if I would have cared, but I didn't even know. So, to me, things are "portable" because it uses MySQL, and MySQL is portable enough. I fully understand (now) that people want to be portable to other databases, but that's never been a real concern of mine.

Mozilla.org uses /usr/bonsaitools/bin/perl. The prime rule in making submissions is "don't break bugzilla.mozilla.org". If it breaks it, your patch will be reverted faster than you can do a diff.

Here's Terry Weissman's comment, for some historical context:

[This was] purely my own convention. I wanted a place to put a version of Perl and other tools that was strictly under my control for the various webtools, and not subject to anyone else. Edit it to point to whatever you like.

We always recommend that, if possible, you keep the path as /usr/bonsaitools/bin/perl, and simply add a /usr/bonsaitools and /usr/bonsaitools/bin directory, then symlink your version of perl to /usr/bonsaitools/bin/perl. This will make upgrading your Bugzilla much easier in the future. Obviously, if you do not have root access to your Bugzilla box, our suggestion is irrelevant.

Red Hat Bugzilla is arguably more user-friendly, customizable, and scalable than stock Bugzilla. Check it out at http://bugzilla.redhat.com and the sources at ftp://people.redhat.com/dkl/. They've set their Bugzilla up to work with Oracle out of the box. Note that Redhat Bugzilla is based upon the 2.8 Bugzilla tree; Bugzilla has made some tremendous advances since the 2.8 release. Why not download both Bugzillas to check out the differences for yourself?

Dave Lawrence, the original Red Hat Bugzilla maintainer, mentions:

Somebody needs to take the ball and run with it. I'm the only maintainer and am very pressed for time.

Dave Lawrence:

For the record, we are not using any template type implementation for the cosmetic changes maded to Bugzilla. It is just alot of html changes in the code itself. I admit I may have gotten a little carried away with it but the corporate types asked for a more standardized interface to match up with other projects relating to Red Hat web sites. A lot of other web based internal tools I am working on also look like Bugzilla.

I do want to land the changes that I have made to Bugzilla but I may have to back out a good deal and make a different version of Red Hat's Bugzilla for checking in to CVS. Especially the cosmetic changes because it seems they may not fit the general public. I will do that as soon as I can. I also still do my regular QA responsibilities along with Bugzilla so time is difficult sometimes to come by.

There are also a good deal of other changes that were requested by management for things like support contracts and different permission groups for making bugs private. Here is a short list of the major changes that have been made:

1. No enum types. All old enum types are now separate smaller tables.

2. No bit wise operations. Not all databases support this so they were changed to a more generic way of doing this task

3. Bug reports can only be altered by the reporter, assignee, or a privileged bugzilla user. The rest of the world can see the bug but in a non-changeable format (unless the bug has been marked private). They can however add comments, add and remove themselves from the CC list

4. Different group scheme. Each group has an id number related to it. There is a user_group table which contains userid to groupid mappings to determine which groups each user belongs to. Additionally there is a bug_group table that has bugid to groupid mappings to show which groups can see a particular bug. If there are no entries for a bug in this table then the bug is public.

5. Product groups. product_table created to only allow certain products to be visible for certain groups in both bug entry and query. This was particulary helpful for support contracts.

6. Of course many (too many) changes to Bugzilla code itself to allow use with Oracle and still allow operation with Mysql if so desired. Currently if you use Mysql it is set to use Mysql's old permission scheme to keep breakage to a minimum. Hopefully one day this will standardize on one style which may of course be something completely different.

7. Uses Text::Template perl module for rendering of the dynamic HTML pages such as enter_bug.cgi, query.cgi, bug_form.pl, and for the header and footer parts of the page. This allows the html to be separate from the perl code for customizing the look and feel of the page to one's preference.

8. There are many other smaller changes. There is also a port to Oracle that I have been working on as time permits but is not completely finished but somewhat usable. I will merge it into our standard code base when it becomes production quality. Unfortunately there will have to be some conditionals in the code to make it work with other than Oracle due to some differences between Oracle and Mysql.

Both the Mysql and Oracle versions of our current code base are available from ftp://people.redhat.com/dkl. If Terry/Tara wants I can submit patch files for all of the changes I have made and he can determine what is suitable for addition to the main bugzilla cade base. But for me to commit changes to the actual CVS I will need to back out alot of things that are not suitable for the rest of the Bugzilla community. I am open to suggestions.

Loki Games has a customized version of Bugzilla available at http://fenris.lokigames.com. There are some advantages to using Fenris, chief being separation of comments based upon user privacy level, data hiding, forced login for any data retrieval, and some additional fields. Loki has mainted their code, originally a fork from the Bugzilla 2.8 code base, and it is quite a bit different than stock Bugzilla at this point. I recommend you stick with official Bugzilla version 2.14 rather than using a fork, but it's up to you.

It is web and e-mail based. You can edit bugs by sending specially formatted email to a properly configured Bugzilla, or control via the web.

Yes! You can find more information elsewhere in "The Bugzilla Guide" in the "Integration with Third-Party Products" section.

Absolutely! You can track up to a "soft-limit" of around 64 individual "Products", that can each be composed of as many "Components" as you want. Check the Administration section of the Bugzilla Guide for more information regarding setting up Products and Components.

Yes.

Yes. There are many specific MIME-types that are pre-defined by Bugzilla, but you may specify any arbitrary MIME-type you need when you upload the file. Since all attachments are stored in the database, however, I recommend storing large binary attachments elsewhere in the web server's file system and providing a hyperlink as a comment, or in the provided "URL" field in the bug report.

Yes. However, modifying some fields, notably those related to bug progression states, also require adjusting the program logic to compensate for the change.

There is no GUI for adding fields to Bugzilla at this time. You can follow development of this feature at http://bugzilla.mozilla.org/show_bug.cgi?id=91037

It's possible to get the footer on the static index page using Server Side Includes (SSI). The trick to doing this is making sure that your web server is set up to allow SSI and specifically, the #exec directive. You should also rename index.html to index.shtml.

After you've done all that, you can add the following line to index.shtml:

<!--#exec cmd="/usr/bin/perl -e &quot;require 'CGI.pl'; PutFooter();&quot;" -->

This line will be replaced with the actual HTML for the footer when the page is requested, so you should put this line where you want the footer to appear.

Because this method depends on being able to use a #exec directive, and most ISP's will not allow that, there is an alternative method. You could have a small script (such as api.cgi) that basically looks like:

#!/usr/bonsaitools/bin/perl -w require 'globals.pl'; if ($::FORM{sub} eq 'PutFooter') { PutFooter(); } else { die 'api.cgi was incorrectly called'; }

and then put this line in index.shtml.

<!--#include virtual="api.cgi?sub=PutFooter"-->

This still requires being able to use Server Side Includes, if this simply will not work for you, see bug 80183 for a third option.

Yes. Look at http://bugzilla.mozilla.org/reports.cgi for basic reporting facilities.

For more advanced reporting, I recommend hooking up a professional reporting package, such as Crystal Reports, and use ODBC to access the MySQL database. You can do a lot through the Query page of Bugzilla as well, but right now Advanced Reporting is much better accomplished through third-party utilities that can interface with the database directly.

Advanced Reporting is a Bugzilla 3.X proposed feature.

Email notification is user-configurable. The bug id and Topic of the bug report accompany each email notification, along with a list of the changes made.

Yes.

Bugzilla email is sent in plain text, the most compatible mail format on the planet.

If you decide to use the bugzilla_email integration features to allow Bugzilla to record responses to mail with the associated bug, you may need to caution your users to set their mailer to "respond to messages in the format in which they were sent". For security reasons Bugzilla ignores HTML tags in comments, and if a user sends HTML-based email into Bugzilla the resulting comment looks downright awful.

Yes. Place yourself in the "cc" field of the bug you wish to monitor. Then change your "Notify me of changes to" field in the Email Settings tab of the User Preferences screen in Bugzilla to the "Only those bugs which I am listed on the CC line" option.

Mozilla allows data export through a custom DTD in XML format. It does not, however, export to specific formats other than the XML Mozilla DTD. Importing the data into Excel or any other application is left as an exercise for the reader.

If you create import filters to other applications from Mozilla's XML, please submit your modifications for inclusion in future Bugzilla distributions.

As for data import, any application can send data to Bugzilla through the HTTP protocol, or through Mozilla's XML API. However, it seems kind of silly to put another front-end in front of Bugzilla; it makes more sense to create a simplified bug submission form in HTML. You can find an excellent example at http://www.mozilla.org/quality/help/bugzilla-helper.html

Currently, no. Internationalization support for Perl did not exist in a robust fashion until the recent release of version 5.6.0; Bugzilla is, and likely will remain (until 3.X) completely non-localized.

Yes. No. No.

Yes.

You can save an unlimited number of queries in Bugzilla. You are free to modify them and rename them to your heart's desire.

You have no idea. Bugzilla's query interface, particularly with the advanced Boolean operators, is incredibly versatile.

Yes.

Bugzilla does not lock records. It provides mid-air collision detection, and offers the offending user a choice of options to deal with the conflict.

MySQL, the database back-end for Bugzilla, allows hot-backup of data. You can find strategies for dealing with backup considerations at http://www.mysql.com/doc/B/a/Backup.html

Yes. However, commits to the database must wait until the tables are unlocked. Bugzilla databases are typically very small, and backups routinely take less than a minute.

If Bugzilla is set up correctly from the start, continuing maintenance needs are minimal and can be completed by unskilled labor. Things like rotate backup tapes and check log files for the word "error".

Commercial Bug-tracking software typically costs somewhere upwards of $20,000 or more for 5-10 floating licenses. Bugzilla consultation is available from skilled members of the newsgroup.

As an example, as of this writing I typically charge $115 for the first hour, and $89 each hour thereafter for consulting work. It takes me three to five hours to make Bugzilla happy on a Development installation of Linux-Mandrake.

It all depends on your level of commitment. Someone with much Bugzilla experience can get you up and running in less than a day, and your Bugzilla install can run untended for years. If your Bugzilla strategy is critical to your business workflow, hire somebody with reasonable UNIX or Perl skills to handle your process management and bug-tracking maintenance & customization.

No. MySQL asks, if you find their product valuable, that you purchase a support contract from them that suits your needs.

Check http://www.mozilla.org/projects/bugzilla/ for details. Once you download it, untar it, read the Bugzilla Guide.

Installation on Windows NT has its own section in "The Bugzilla Guide".

At present, no.

Run mysql like this: "mysqld --skip-grant-tables". Please remember this makes mysql as secure as taping a $100 to the floor of a football stadium bathroom for safekeeping. Please read the Security section of the Administration chapter of "The Bugzilla Guide" before proceeding.

The Bugzilla code has not undergone a complete security audit. It is recommended that you closely examine permissions on your Bugzilla installation, and follow the recommended security guidelines found in The Bugzilla Guide.

This is a common problem, related to running out of file descriptors. Simply add "ulimit -n unlimited" to the script which starts mysqld.

With the email changes to 2.12, the user should be able to set this in user email preferences.

Edit the param for the mail text. Replace "To:" with "X-Real-To:", replace "Cc:" with "X-Real-CC:", and add a "To: (myemailaddress)".

Try Klaas Freitag's excellent patch for "whineatassigned" functionality. You can find it at http://bugzilla.mozilla.org/show_bug.cgi?id=6679. This patch is against an older version of Bugzilla, so you must apply the diffs manually.

You can call bug_email.pl directly from your aliases file, with an entry like this:

bugzilla-daemon: "|/usr/local/bin/bugzilla/contrib/bug_email.pl"

You can find an updated README.mailif file in the contrib/ directory of your Bugzilla distribution that walks you through the setup.

If you are using an alternate Mail Transport Agent (MTA other than sendmail), make sure the options given in the "processmail" script for all instances of "sendmail" are correct for your MTA.

If you are using Sendmail, try enabling "sendmailnow" in editparams.cgi. If you are using Postfix, you will also need to enable "sendmailnow".

Double-check that you have not turned off email in your user preferences. Confirm that Bugzilla is able to send email by visiting the "Log In" link of your Bugzilla installation and clicking the "Email me a password" button after entering your email address.

If you never receive mail from Bugzilla, chances you do not have sendmail in "/usr/lib/sendmail". Ensure sendmail lives in, or is symlinked to, "/usr/lib/sendmail".

Red Hat Bugzilla, mentioned above, works with Oracle. The current version from Mozilla.org does not have this capability. Unfortunately, though you will sacrifice a lot of the really great features available in Bugzilla 2.10 and 2.12 if you go with the 2.8-based Redhat version.

You've almost certainly enabled the "shadow database", but for some reason it hasn't been updated for all your bugs. This is the database against which queries are run, so that really complex or slow queries won't lock up portions of the database for other users. You can turn off the shadow database in editparams.cgi. If you wish to continue using the shadow database, then as your "bugs" user run "./syncshadowdb -syncall" from the command line in the bugzilla installation directory to recreate your shadow database. After it finishes, be sure to check the params and make sure that "queryagainstshadowdb" is still turned on. The syncshadowdb program turns it off if it was on, and is supposed to turn it back on when completed; that way, if it crashes in the middle of recreating the database, it will stay off forever until someone turns it back on by hand. Apparently, it doesn't always do that yet.

Run the "sanity check" utility (./sanitycheck.cgi in the Bugzilla_home directory) from your web browser to see! If it finishes without errors, you're probably OK. If it doesn't come back OK (i.e. any red letters), there are certain things Bugzilla can recover from and certain things it can't. If it can't auto-recover, I hope you're familiar with mysqladmin commands or have installed another way to manage your database. Sanity Check, although it is a good basic check on your database integrity, by no means is a substitute for competent database administration and avoiding deletion of data. It is not exhaustive, and was created to do a basic check for the most common problems in Bugzilla databases.

There is no facility in Bugzilla itself to do this. It's also generally not a smart thing to do if you don't know exactly what you're doing. However, if you understand SQL you can use the mysqladmin utility to manually insert, delete, and modify table information. Personally, I use "phpMyAdmin". You have to compile a PHP module with MySQL support to make it work, but it's very clean and easy to use.

Certain version of MySQL (notably, 3.23.29 and 3.23.30) accidentally disabled the "crypt()" function. This prevented MySQL from storing encrypted passwords. Upgrade to the "3.23 stable" version of MySQL and you should be good to go.

Try running MySQL from its binary: "mysqld --skip-grant-tables". This will allow you to completely rule out grant tables as the cause of your frustration. However, I do not recommend you run it this way on a regular basis, unless you really want your web site defaced and your machine cracked.

Well, you can synchronize or you can move bugs. Synchronization will only work one way -- you can create a read-only copy of the database at one site, and have it regularly updated at intervals from the main database.

MySQL has some synchronization features builtin to the latest releases. It would be great if someone looked into the possibilities there and provided a report to the newsgroup on how to effectively synchronize two Bugzilla installations.

If you simply need to transfer bugs from one Bugzilla to another, checkout the "move.pl" script in the Bugzilla distribution.

If you're sure your MySQL parameters are correct, you might want turn "strictvaluechecks" OFF in editparams.cgi. If you have "usebugsentry" set "On", you also cannot submit a bug as readable by more than one group with "strictvaluechecks" ON.

This should only happen with Bugzilla 2.14 if you are using the "shadow database" feature, and your shadow database is out of sync. Try running syncshadowdb -syncall to make sure your shadow database is in synch with your primary database.

Remove Windows. Install Linux. Install Bugzilla. The boss will never know the difference.

Not currently. Bundle::Bugzilla enormously simplifies Bugzilla installation on UNIX systems. If someone can volunteer to create a suitable PPM bundle for Win32, it would be appreciated.

Depending on what Web server you are using, you will have to configure the Web server to treat *.cgi files as CGI scripts. In IIS, you do this by adding *.cgi to the App Mappings with the <path>\perl.exe %s %s as the executable.

Microsoft has some advice on this matter, as well:

"Set application mappings. In the ISM, map the extension for the script file(s) to the executable for the script interpreter. For example, you might map the extension .py to Python.exe, the executable for the Python script interpreter. Note For the ActiveState Perl script interpreter, the extension .pl is associated with PerlIS.dll by default. If you want to change the association of .pl to perl.exe, you need to change the application mapping. In the mapping, you must add two percent (%) characters to the end of the pathname for perl.exe, as shown in this example: c:\perl\bin\perl.exe %s %s"

The following couple entries are deprecated in favor of the Windows installation instructions available in the "Administration" portion of "The Bugzilla Guide". However, they are provided here for historical interest and insight.

  1. #!C:/perl/bin/perl had to be added to every perl file.
  2. Converted to Net::SMTP to handle mail messages instead of
     /usr/bin/sendmail.
  3. The crypt function isn't available on Windows NT (at least none that I
     am aware), so I made encrypted passwords = plaintext passwords.
  4. The system call to diff had to be changed to the Cygwin diff.
  5. This was just to get a demo running under NT, it seems to be working
     good, and I have inserted almost 100 bugs from another bug tracking
     system. Since this work was done just to get an in-house demo, I am NOT
     planning on making a patch for submission to Bugzilla. If you would
     like a zip file, let me know.

Q: Hmm, couldn't figure it out from the general instructions above.  How
about step-by-step?
A: Sure! Here ya go!

  1. Install IIS 4.0 from the NT Option Pack #4.
  2. Download and install Active Perl.
  3. Install the Windows GNU tools from Cygwin. Make sure to add the bin
     directory to your system path. (Everyone should have these, whether
     they decide to use Bugzilla or not. :-) )
  4. Download relevant packages from ActiveState at
     http://www.activestate.com/packages/zips/. + DBD-Mysql.zip
  5. Extract each zip file with WinZip, and install each ppd file using the
     notation: ppm install <module>.ppd
  6. Install Mysql.  *Note: If you move the default install from c:\mysql,
     you must add the appropriate startup parameters to the NT service. (ex.
     -b e:\\programs\\mysql)
  7. Download any Mysql client. http://www.mysql.com/download_win.html
  8. Setup MySql. (These are the commands that I used.)

          I. Cleanup default database settings.
           C:\mysql\bin\mysql -u root mysql
           mysql> DELETE FROM user WHERE Host='localhost' AND User='';
           mysql> quit
          C:\mysql\bin\mysqladmin reload

          II. Set password for root.
           C:\mysql\bin\mysql -u root mysql
           mysql> UPDATE user SET Password=PASSWORD('new_password')
           WHERE user='root';
           mysql> FLUSH PRIVILEGES;
           mysql> quit
           C:\mysql\bin\mysqladmin -u root reload

          III. Create bugs user.
           C:\mysql\bin\mysql -u root -p
           mysql> insert into user (host,user,password)
          values('localhost','bugs','');
           mysql> quit
           C:\mysql\bin\mysqladmin -u root reload

          IV. Create the bugs database.
           C:\mysql\bin\mysql -u root -p
           mysql> create database bugs;

          V. Give the bugs user access to the bugs database.
           mysql> insert into db
          (host,db,user,select_priv,insert_priv,update_priv,delete_priv,create_priv,drop_priv)
          values('localhost','bugs','bugs','Y','Y','Y','Y','Y','N')
           mysql> quit
           C:\mysql\bin\mysqladmin -u root reload
  9. Run the table scripts to setup the bugs database.
 10. Change CGI.pm to use the following regular expression because of
     differing backslashes in NT versus UNIX.
        o $0 =~ m:[^\\]*$:;
 11. Had to make the crypt password = plain text password in the database.
     (Thanks to Andrew Lahser" <andrew_lahser@merck.com>" on this one.) The
     files that I changed were:
        o globals.pl
        o CGI.pl
        o alternately, you can try commenting all references to 'crypt'
          string and replace them with similar lines but without encrypt()
          or crypr() functions insida all files.
 12. Replaced sendmail with Windmail. Basically, you have to come up with a
     sendmail substitute for NT. Someone said that they used a Perl module
     (Net::SMTP), but I was trying to save time and do as little Perl coding
     as possible.
 13. Added "perl" to the beginning of all Perl system calls that use a perl
     script as an argument and renamed processmail to processmail.pl.
 14. In processmail.pl, I added binmode(HANDLE) before all read() calls. I'm
     not sure about this one, but the read() under NT wasn't counting the
     EOLs without the binary read."
    

Your modules may be outdated or inaccurate. Try:

1. Hitting http://www.activestate.com/ActivePerl

2. Download ActivePerl

3. Go to your prompt

4. Type 'ppm'

5. PPM> install DBI DBD-mysql GD

We are developing in that direction. You can follow progress on this at http://bugzilla.mozilla.org/show_bug.cgi?id=16775. Some functionality is available in Bugzilla 2.12, and is available as "quicksearch.html"

The current behavior is acceptable to bugzilla.mozilla.org and most users. I personally don't like it. You have your choice of patches to change this behavior, however.

The most likely cause is a very old browser or a browser that is incompatible with file upload via POST. Download the latest Netscape, Microsoft, or Mozilla browser to handle uploads correctly.

Yup. Just rename it once you download it, or save it under a different filename. This will not be fixed anytime too soon, because it would cripple some other functionality.

In the Bugzilla administrator UI, edit the keyword and it will let you replace the old keyword name with a new one. This will cause a problem with the keyword cache. Run sanitycheck.cgi to fix it.

Try this link to view current bugs or requests for enhancement for Bugzilla.

You can view bugs marked for 2.16 release here. This list includes bugs for the 2.16 release that have already been fixed and checked into CVS. Please consult the Bugzilla Project Page for details on how to check current sources out of CVS so you can have these bug fixes early!

This is well-documented here: http://bugzilla.mozilla.org/show_bug.cgi?id=49862. Ultimately, it's as easy as adding the "---" priority field to your localconfig file in the appropriate area, re-running checksetup.pl, and then changing the default priority in your browser using "editparams.cgi". Hmm, now that I think about it, that is kind of a klunky way to handle it, but for now it's what we have! Although the bug has been closed "resolved wontfix", there may be a better way to handle this...

1. Enter a bug into bugzilla.mozilla.org for the "Bugzilla" product.

2. Upload your patch as a unified DIFF (having used "diff -u" against the current sources checked out of CVS), or new source file by clicking "Create a new attachment" link on the bug page you've just created, and include any descriptions of database changes you may make, into the bug ID you submitted in step #1. Be sure and click the "Patch" radio button to indicate the text you are sending is a patch!

3. Announce your patch and the associated URL (http://bugzilla.mozilla.org/show_bug.cgi?id=XXXX) for discussion in the newsgroup (netscape.public.mozilla.webtools). You'll get a really good, fairly immediate reaction to the implications of your patch, which will also give us an idea how well-received the change would be.

4. If it passes muster with minimal modification, the person to whom the bug is assigned in Bugzilla is responsible for seeing the patch is checked into CVS.

5. Bask in the glory of the fact that you helped write the most successful open-source bug-tracking software on the planet :)