Open-Source Bug Tracking with Bugzilla
Simplicity is the key to an easy-to-use system. Bugzilla comes set up with extensive lists of operating systems, priorities a bug can have and states a bug can be in. It is important for an efficient work flow that you adapt these to your specific needs. This is true especially for priorities, which Bugzilla calls Severities. I know no environment that requires as many priority levels as come with Bugzilla originally. Usually no more than three severities are needed: high (or showstopper) for major bugs that cause production stops or block other people from completing their work, medium for most normal bugs and low for minor issues such as typos. Any more than these cause confusion.
Similar rules apply to the state that a bug can be in. The states should reflect your normal work flow, not the other way around. A standard set of states may include New, Accepted, In Progress/Open, Resolved, Not a Bug and Tested/Completed.
These are all simple tasks, but thinking about them initially and communicating them with your teams in the early stages of rollout prevents confusion and guarantees a smooth introduction of the new tool.
To install Bugzilla, get the latest version from bugzilla.org. Although version 2.16.3 is declared as the latest stable release, I have found no problems with the many 2.17.4 installations we have running. This newer release also has many interesting extra features. You also need Perl 5.6 or higher, a running MySQL Database, minimum version 3.23.41. With a little manual tweaking, databases such as Oracle and Postgres also work well. Finally, you need a running Web server—Apache, of course, is recommended.
The installation process is pretty straightforward. After installing a number of Perl libraries and setting up a database user dedicated to Bugzilla, the installation basically consists of copying the contents of the tarball to your Web space and running the checksetup.pl script located in the main Bugzilla directory. This magic script sets up the vitals, including the administrative user and access permissions. It also creates a file named localconfig. This file's contents are self-explanatory and include, for example, the database connection settings. Be sure to install the Perl packages that are declared optional and a package called dot (part of GraphViz). These extra packages allow for enhanced graph and reporting capabilities.
While you are at it, include the collectstats.pl script, which allows for the nifty bug history graphs in your crontab. After running checksetup.pl again, you are able to access a fully functional Bugzilla in your Web browser. In the footer of the start page you should find a link entitled Edit parameters. Run through the settings on this page and set them as appropriate.
The most important settings include:
maintainer: the e-mail address of the person responsible for maintaining this Bugzilla installation. The address need not be that of a valid Bugzilla account.
urlbase: defines the fully qualified domain name and Web server path to your Bugzilla installation.
whinedays: set to the number of days you want to allow a bug to remain in either the NEW or REOPENED state before notifying the responsible party that he or she has untouched new bugs. If you do not plan on using this feature, simply do not set up the whining cronjob described in the installation instructions above, or set this value to 0.
commenton*: each of these fields allow you to dictate which changes can pass without comment and which must be commented upon by the changer. Usually it makes sense to allow users to add themselves to the CC list, accept bugs and change the Status Whiteboard without adding comments about the reasons for the change, yet require that most other changes come with an explanation.
Users can create their own user accounts by clicking the New Account link at the bottom of each page, assuming they aren't logged in already. However, should you wish to create user accounts ahead of time, here is how you do it. After logging in, click the Users link at the footer of the query page and then click Add a new user. Fill out the form and click on Submit. Make sure to restrict your user's rights to reasonable access levels.
In addition to adding users for each member of the team, you also may want to create an anonymous user. This can be useful for allowing external persons, such as customers using your Web site, to submit a bug without the added overhead of creating a new user account. Now is also a good time to set up your products and related components, as discussed earlier. Don't forget to insert meaningful descriptions and assign the right person to each component.
The last step is to set up the correct lists of used operating systems, bug states and priorities for the system. All of these settings can be altered and improved upon later without problems or downtime, but try to prepare as much as possible now to avoid confusion among the users and improve the smooth integration of Bugzilla in your work flow.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- I once had a better way I
1 hour 4 sec ago
- Not only you I too assumed
1 hour 17 min ago
- another very interesting
3 hours 10 min ago
- Reply to comment | Linux Journal
5 hours 3 min ago
- Reply to comment | Linux Journal
11 hours 57 min ago
- Reply to comment | Linux Journal
12 hours 14 min ago
- Favorite (and easily brute-forced) pw's
14 hours 5 min ago
- Have you tried Boxen? It's a
19 hours 57 min ago
- seo services in india
1 day 28 min ago
- For KDE install kio-mtp
1 day 29 min ago