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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide