Bugzilla Interview Preparation Guide

Download PDF

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.

Yes. Look at http://link.GlobalGuideline.com 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. 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.

Currently, no.

Yes.

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

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.

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"

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.

The current version does not have this capability.

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.

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.

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.

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.

Installation of bugzilla is pretty straightforward, particularly if your machine already has MySQL and the MySQL-related perl packages installed.

The software packages necessary for the proper running of bugzilla are:
1. MySQL database server and the mysql client (3.22.5 or greater)
2. Perl (5.004 or greater, 5.6.1 is recommended if you wish to use Bundle::Bugzilla)
3. DBI Perl module
4. Data::Dumper Perl module
5. Bundle::Mysql Perl module collection
6. TimeDate Perl module collection
7. GD perl module (1.8.3) (optional, for bug charting)
8. Chart::Base Perl module (0.99c) (optional, for bug charting)
9. DB_File Perl module (optional, for bug charting) 9. 10.The web server of your choice. Apache is recommended.
11.MIME::Parser Perl module (optional, for contrib/bug_email.pl interface)

You should untar the Bugzilla files into a directory that you're willing to make writable by the default web server user (probably "nobody"). You may decide to put the files off of the main web space for your web server or perhaps off of /usr/local with a symbolic link in the web space that points to the Bugzilla directory. At any rate, just dump all the files in the same place, and make sure you can access the files in that directory through your web server.

Once all the files are in a web accessible directory, make that directory writable by your webserver's user. This is a temporary step until you run the post-install checksetup.pl script, which locks down your installation.
Lastly, you'll need to set up a symbolic link to /usr/bonsaitools/bin/perl for the correct location of your perl executable (probably /usr/bin/perl). Otherwise you must hack all the .cgi files to change where they look for perl, or use The setperl.csh Utility, found in Useful Patches and Utilities for Bugzilla. I suggest using the symlink approach for future release compatability.
After you've gotten all the software installed and working you're ready to start preparing the database for its life as a the back end to a high quality bug tracker.
First, you'll want to fix MySQL permissions to allow access from Bugzilla. For the purpose of this Installation section, the Bugzilla username will be "bugs", and will have minimal permissions.
Next, we create the "bugs" user, and grant sufficient permissions for checksetup.pl, which we'll use later, to work its magic. This also restricts the "bugs" user to operations within a database called "bugs", and only allows the account to connect from "localhost". Modify it to reflect your setup if you will be connecting from another machine or as a different user.
Remember to set bugs_password to some unique password.

mysql > GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,
ALTER,CREATE,DROP,REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY
'bugs_password';
mysql> FLUSH PRIVILEGES;

Next, run the magic checksetup.pl script.
It will make sure Bugzilla files and directories have reasonable permissions, set up the data directory, and create all the MySQL tables.
bash# ./checksetup.pl
The first time you run it, it will create a file called localconfig.

What's localconfig for ?
This file contains a variety of settings you may need to tweak including how Bugzilla should connect to the MySQL database.

The connection settings include:
1. server's host: just use "localhost" if the MySQL server is local
2. database name: "bugs" if you're following these directions
3. MySQL username: "bugs" if you're following these directions
4. Password for the "bugs" MySQL account above

You should also install .htaccess files that the Apache webserver will use to restrict access to Bugzilla data files. Once you are happy with the settings, re-run checksetup.pl. On this second run, it will create the database and an administrator account for which you will be prompted to provide information. When logged into an administrator account once Bugzilla is running, if you go to the query page (off of the Bugzilla main menu), you'll find an "edit parameters" option that is filled with editable treats. Should everything work, you will have a nearly empty Bugzilla database and a newly-created localconfig file in your Bugzilla root directory.

The second time you run checksetup.pl, you should become the user your web server runs as, and that you ensure that you set the "webservergroup" parameter in localconfig to match the web server's group name, if any. I believe, for the next release of Bugzilla, this will be fixed so that Bugzilla supports a "webserveruser" parameter in localconfig as well.

To enter a bug, select Enter a new bug from the main bugzilla page. This will take you to a product selection screen.
From this screen you select the product that you wish to enter a bug for, by selecting the hightlighted product name. This will take you to a bug entry screen.
Example: Red Hat Linux
From the bug entry screen, you need to select the version of the product that you are entering a bug on, along with which component of the product that is having a problem. Components are based on the source rpm that the offending binary rpm is derived from. To find the proper component do you can use one of two common methods:
$ rpm -qip 'binary rpm name'
This should work fine if you already know which rpm the failing binary belongs to.
$ rpm -qif /failing/binary
This will tell you which rpm the binary belongs to and also the source rpm.
After using one of the above methods look for a line that says Source RPM: This is the name of the component you should choose from the list of components in Bugzilla. If still unsure of which component to choose or you are filing a bug to request a new component be added to Bugzilla itself, then choose distribution.
Example: 5.2 and acm
Next, select the Severity of your bug.
Example: Normal.
Then you will select which Architecture your bug occurs on.
Example: If you are using an Intel x86 platform, you will choose i386.
The Cc: field can be used to add someone to the carbon-copy list for all email related to this bug. As the reporter of the bug, you will automatically be copied on any mail, so you do not need to add yourself to this.
Enter a one line description of the bug into the Summary field, and the full description of the bug into the Description field.

To search for a bug, select Go to the query page from the main bugzilla page.
The bugzilla search uses an "OR" within each field, with an "AND" between fields. So, if you were to select NEW and VERIFIED from the Status field and normal from the Priority field, you would be asking for all normal priority bugs that are new or verified.

Yes. If you do not have cookies enabled or are using a browser that does not support cookies, you will be prompted to re-login for each screen. It also allows for special features like stored queries and keeping track of your last query result list.

A. In general, no. First, every piece of code needs to be written and maintained, both of which take developer time away from bugs and other features. Second, each added preference makes all other preferences slightly less accessible. Camino’s goal is to be lightweight, which means keeping the number of preferences down as well.

A. Camino is developed entirely by a small group of volunteers, working in their free time. Limited developer time means that some bugs and feature requests can wait for months, or even years, until someone has time to address them. The order bugs are fixed in depends on overall project priorities, as well as the difficulty of bugs and the skills and interests of individual developers. Do not complain in a bug or ask why it hasn’t been fixed yet—see the Bugzilla etiquette. The only way to get bugs fixed faster is to contribute in some way (such as fixing them yourself, helping to recruit new developers, or helping out in some other way that frees up developers to spend more time on coding).
Demanding that a bug be fixed, whining, threatening to switch browsers, etc., is always counter-productive. Fixing bugs is simply a question of manpower and complaining in a bug wastes the time of everyone reading bug reports or following the progress of a bug via email.

A. Follow the instructions above for reporting a bug, but pick “Enhancement” as the severity at the last step.

A. Camino has entered a “hung” state; the only way to end this state is to “force quit” Camino. If you can reproduce the situation, file a bug. Be sure to set the severity to “critical”, add “hang” in the keyword field, and have the following things handy: the URL on which the hang occurred (if the hang was browsing-related), detailed steps to reproduce the hang (if some action was required), and a sample of Camino while it is in the hung state.
Before you force quit Camino, open the Activity Monitor application located in the Utilities subfolder of the Applications folder. On launch, the application should display a window listing various “processes” that are running on your Mac. Select Camino from the list and then click the “Inspect” button. In the window that opens, click the “Sample” button; this will generate a log that will help the developers determine why Camino entered the hung state. When the sample is complete, save the file; you may now close the sample window and force quit Camino.
After you have filed your initial bug report, attach the sample file to the bug using the “Create a New Attachment” link. Please do not paste samples into the “Comments” field of the bug report.

A. Bugs for Camino are managed through a system called Bugzilla. To report a bug, just go to the bug reporting helper and follow the instructions. Be sure to take the time to search for duplicates in step 1, since repeated reports of the same issue waste both your and developers’ time.
If you’ve never used the system before, you’ll need to create an account first. Creating an account is extremely quick and easy.

A. Camino’s goal is to be lightweight and easy to use. That means that it can’t include every feature that is ever requested. Invariably, some people will be unhappy with the decisions that are made regarding which features aren’t included, but strong leadership is necessary to keep Camino true to its vision. WONTFIX decisions are made by the Camino lead, are made for good reason (even if not explained in the bug), and as such are final. Do not complain or argue in a bug that has been marked WONTFIX. Unless you have new, compelling information to add, do not comment in the bug. Please remember that “x people I talked to said this is really important” is not compelling information. Unless you have have done a statistically valid sample of Camino’s entire target user base (and neither Bugzilla nor online forums are representative samples), you aren’t going to convince anyone.