Open-Source Bug Tracking with Bugzilla
Bug Tracking Systems (BTS) have their origin in software development, but they can serve as important and useful tools in every team environment. For this reason the names Issue Tracker or Ticket System have become more appropriate.
BTS may function as a central point of communication for any team. They can increase the productivity and accountability of each employee dramatically by providing a documented work flow and allowing for positive feedback on good performance. They usually reduce downtime and production costs while increasing efficiency and, most importantly, customer satisfaction.
The open-source project Bugzilla, for example, provides an easy to use, easy to maintain and cost effective solution with a rich feature set that easily can compete with its proprietary counterparts. Bugzilla's Web interface allows cross-platform use while the XML and e-mail interfaces enable automatic error reporting. Not only can the automatic error reporting be included in the development of a new product, but it also can be integrated easily into an existing product.
This article provides an overview of how introducing Bugzilla can help your team work together and communicate more efficiently. Bugzilla uses the term bug, so I will stay with this notation throughout the article, but don't forget, it's not only about bugs, You can use Bugzilla for any task you need to track.
Bug trackers aid the whole product life-cycle. In the case of software development environments, this usually consists of software design, implementation and testing. From testing, the work flow takes it course either back to design or on to implementation for bug fixing. In the best of all worlds, at some point an error-free product leaves this cycle and gets shipped to a customer. In all other worlds, the customer is part of the development cycle and submits bugs.
Everyone in the team needs to effectively keep track of upcoming issues. Designers and developers need to be notified about new bugs and reminded of existing ones. Managers need a means to distribute upcoming bugs to the right developer and quickly acquire the status of the project. Integrators and testers need to know which issues already have been resolved and therefore require consideration in the next build and test cycle. Customers want to be able to rapidly report bugs and receive an update of their status, while help desk operators need to be able to respond quickly to such customer demands.
Most companies come to the point where they start to track those issues by way of e-mail or spreadsheet lists—some even use sticky notes. At some point, the number of issues outgrows these approaches and the number of forgotten or unresolved issues demands a better solution. Let's follow one of those teams on their path to introducing Bugzilla as its in-house BTS.
As with every software product, the introduction of a BTS in an existing work flow requires initial thought and planning. The goal is for all participants to accept and use the new system, meaning that its introduction should have only a positive impact on their daily work.
As with most BTS, bugs in Bugzilla concern a component, which belongs to a product. A bug also may have a version and a milestone attached. Before introducing the new system, thought must be put into how its structure fits in to your daily work flow. All possible upcoming issues in your work flow should have a set place, including problems with Bugzilla itself. It often makes sense to include even trivial organizational issues that can have a large impact on development. If having sufficient blank CDs in your office is critical, you may include a shortage as a bug in Bugzilla.
Products are the main category and usually represent actual shipping products or services. You also should have a number of special products that reflect your internal work groups, like System Administration or Office Supplies.
Components are sub-sections of a product. Among others, a software product may have GUI and Database components. Your special product, system administration, may have the components Intranet Web Site, Shared Drive and Printers, to mention a few. Each component has at least one designated user that receives the error reports. Naturally you want to ensure that the workload is distributed evenly.
Versions refer to the version of your product where the bug occurred, while milestones represent target times for a bug to be fixed by. This does not necessarily need to be a date; it can be something like “When boss returns from holiday”.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
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.Register Now!
- SourceClear Open
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- 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