What is Bugzilla?

Bugzilla is an open source web based bug tracking program that, as the name suggests, was created by the Mozilla Foundation. The program was first developed by Netscape in 1998 when it relicensed its Netscape Navigator under an open-source license as the original Mozilla suite. The software allows users to submit tickets and for project members to assign bugs a severity level and to assign bugs to specific developers.

Bug tracking systems allow individual or groups of developers effectively to keep track of outstanding problems with their product.

It is primarily developed to track bugs for Mozilla’s various projects, including the Firefox browser and the Thunderbird email client. It is an example of “dogfooding,” or a company actually using the products they are developing. Besides Mozilla, Bugzilla is also used for several other major open-source projects, including FreeBSD, WebKit, the Linux Kernel and GNOME, among others.

Bugzilla is a robust, fully featured and mature defect tracking system. Defect tracking systems allow teams of developers to keep track of outstanding bugs, problems, issues, enhancement and other change requests in their products effectively.

Bugzilla is both free as in freedom and free as in price. Despite being free, Bugzilla has many features which are lacking in both its expensive and free counterparts. Consequently, Bugzilla is used by thousands of organizations across the globe.

Bugzilla is famous for its unusual message when no bugs are found in its search engine, “zarro boogs found.” It is intended to be a humorous statement that no software is completely free of bugs by intentionally misspelling the message that no bugs have been found.

A Brief History of Bugzilla

When mozilla.org first came online in 1998, one of the first products that was released was Bugzilla, a bug system implemented using freely available open source tools. Bugzilla was originally written in TCL by Terry Weissman for use at mozilla.org to replace the in-house system then in use at Netscape. The initial installation of Bugzilla was deployed to the public on a mozilla.org server on April 6, 1998.

After a few months of testing and fixing on a public deployment, Bugzilla was finally released as open source via anonymous CVS and available for others to use on August 26, 1998. At this point. Terry decided to port Bugzilla to Perl, with the hopes that more people would be able to contribute to it, since Perl seemed to be a more popular language. The completion of the port to Perl was announced on September 15, 1998, and committed to CVS later that night.

After a few days it was released as Bugzilla 2.0 on September 19, 1998. Since then a large number of projects, both commercial and free have adapted it as their primary method of tracking software defects. In April of 2000, Terry handed off control of the Bugzilla project to Tara Hernandez. Under Tara’s leadership, some of the regular contributors were coerced into taking more responsibility, and Bugzilla began to truly become a group effort. In July of 2001, facing lots of distraction from her “real job,” Tara handed off control to Dave Miller, who is still in charge as of this writing.

On November 30, 2017 Dylan Hardison announced the Harmony project which aims to harmonize the version of Bugzilla used internally by Mozilla with the open source project. Note there are lots of references to “BMO” which stands for bugzilla.mozilla.org.

Email – Productivity Killer or Killer App?

process that emailEmail is often the #1 focus for advice on how to be more productive. Tactics like “don’t process email first thing” or “batch your email twice a day” are commonplace on the web.

Paul Graham wrote the seminal article Maker’s Schedule, Manager’s Schedule back in 2009 where he discussed why meetings destroy productivity for makers since it takes so long for a maker to achieve the productive “flow” state. The concept behind this is sound and why I think so many give the email advice they do.

Maker or Manager Email?

However, the advice often doesn’t distinguish between makers and managers. Ignoring your email (or at least batching it) is sound advice for makers, but it is suicide for managers.

My job as a manager is communication. How can I do my job well if I ignore one of the primary modes of communication? That is like telling a salesperson to ignore the phone.

Now I will be the first to admit that there is lots of non-productive email so the trick is not to ignore all your email, but to triage it. There are several systems out there such as David Allen’s Getting Things Done which you can use for the actual tactics, but the point is you need to have some kind of system.

My morning routine is in direct opposition to most email advice. I spend the first hour or 2 of every day responding to email. Why? Because other people are waiting on decisions or information that I provide. Without my input they can’t proceed and that impedes their productivity and my goal it to get them working again as soon as possible.

Now I know some of you are thinking that I shouldn’t be the bottleneck or that I am micromanaging my team. I will just just point out that my team members have lots of latitude to make decisions, but occasionally my input is needed. This probably represents 1% of my emails.

The next bulk of the emails (40-50%) are informational so that I know how the business/project is going. These emails may spawn other emails as I keep various stakeholders in the loop.

Then there is a small number of “educational” emails which are typically mailing lists I’ve subscribed to. These get processed last and are typically skimmed. If there is something interesting or worth more attention I flag them and move on.

The rest of it is junk and I just delete it.

Does this process burn up my best and most productive hours of the day? Nope, because I’m not a maker.

Bugzilla Plugin for Helga Chat Bot

Helga is a Python chat bot. Full documentation can be found at http://helga.readthedocs.org.

The Bugzilla plugin allows Helga to respond to Bugzilla ticket numbers in IRC and print information about the tickets. For example:

03:14 <devzing> bz 123 
03:14 <helgabot> devzing might be talking about 
    https://app.devzing.com/demo/bugzilla/show_bug.cgi?id=123 
    [[TestProduct] Ticketing Box City selector]

Find out more at https://github.com/ktdreyer/helga-bugzilla

Access Bugzilla from Python

The python-bugzilla package is available on GitHub or PyPi

pip install python-bugzilla

This package provides two bits:

  • ‘bugzilla’ python module for talking to a Bugzilla instance over XMLRPC
  • /usr/bin/bugzilla command line tool for performing actions from the command line: create or edit bugs, various queries, etc.

This was originally written specifically for Red Hat’s Bugzilla instance and is used heavily at Red Hat and in Fedora, but it should still be generically useful.

Example

import bugzilla
bz = bugzilla.Bugzilla(url="https://bugzilla.kernel.org")
print bz.getbug(1)

 

Import a CSV file into MantisBT

​​First enable the import plugin

  • Log into Mantis
  • click Manage
  • click Manage Plugins
  • find Mantis CSV Importer 1.4.0 and click Install

2015-02-28_1309

Import your data

  • save your bug list as a CSV file – be sure to save one file per project otherwise you will have to reassign the bugs to the correct project one by one.
  • Log into Mantis
  • click Manage
  • choose the project that matches the file you want to import (top right dropdown)
  • click Import CSV file

import dialog

  • click Choose File and find the CSV file you saved earlier
  • click Upload File
  • match the columns from your file with the fields in MantisBT. Don’t choose the “ID” column as this is only used for updating existing bugs.
  • click Import File

Bugzilla 5.0 is right around the corner

Bugzilla 5.0 is right around the corner and honestly we’re a little excited.

Are you an early adopter?

Bugzilla 5.0rc2 is available now if you like to live on the bleeding edge. There aren’t any changes expected between now and when 5.0 is officially released in a couple of weeks. If you are interested in upgrading just let support know and we’ll take care of it.

Don’t have Bugzilla? Support can add it to your account at any time.

Don’t have an account? Get started in under a minute.

For everyone else we will follow our typical upgrade process. We will test 5.0 ourselves and monitor any issues other people in the community are running into. Once we are confident that 5.0 is stable enough we will send out an announcement about when the upgrade will happen and give you the option to opt out.

Here are some highlights of what you have to look forward to:

Improved WebServices

This release has major improvements in the WebServices interface. One big addition is a new REST-like endpoint alongside the existing XML-RPC and JSON-RPC endpoints. This will allow clients to access Bugzilla data using standard HTTP calls for easy development.

Several methods have been added and existing ones improved to allow returning data that was not available before such as Group.get. Bug.search is now as full featured as the Advanced Query UI allowing for the same searches to be executed. Attachment data such as flags and other metadata can now be updated through the API.

Also API key support has been added so that API calls will no longer need to use cookies or a user’s login and password.

Ability to Tag Bug Comments

Users can add tags, visible to other users, to bug comments. This gives the users the ability to thread conversations, mark comments as spam, identify important comments, etc. Users can hide comments that contain specific tags if desired. The tag input field also supports autocompletion so commonly used tags can be selected. Administrators can make specifically tagged comments be automatically hidden from view.

Other Improvements

There is now a “Preview” mode when creating a new comment that allows you to see how the comment will look before committing to the database. This will let you see the results of the “autolinkification” of bug references and links.

Bugs can now have multiple aliases assigned to them. Before each bug could only have a single value. Also, aliases are now visible in the browser’s title bar.

You can now choose to not receive any mail at all about a particular bug, even if you continue to have a role on that bug (e.g. reporter).

Some useful searches have been added to the Bugzilla home page.

Quicksearch now allows for use of comparison operators such as !=, >=, >, <, etc., in addition to substring searches.

The “Blocks” and “Depends On” values can now be displayed as columns in a bug list.

There are now INTEGER and DATE custom field types.

Bugzilla is now HTML5 compliant.

When a site administrator creates a new user, an email is sent to the user.

What isn’t included

Unfortunately the “Make Bugzilla Pretty” effort stalled and was replaced by incorporating the theme used by bugzilla.mozilla.org which also unfortunatly did not make it into 5.0, but is rescheduled to 6.0.

GHOST Attack

Another exploit has been discovered which affects many Linux servers. The moniker is GHOST.

During a code audit performed internally at Qualys, we discovered a
buffer overflow in the __nss_hostname_digits_dots() function of the GNU
C Library (glibc). This bug is reachable both locally and remotely via
the gethostbyname*() functions, so we decided to analyze it — and its
impact — thoroughly, and named this vulnerability “GHOST”.

As of yesterday all our servers were patched with the newest glibc version.

Attack of the Poodle

A new security attack (dubbed the POODLE attack) makes continued use of SSLv3 dangerous. So effective immediately, we are dropping support for SSLv3. Browser users will likely see minimal-to-no impact. If you are having an issue please try a newer version of your browser.

Extremely old browsers (specifically IE 6 users on Windows XP) will no longer be able to connect to devZing pages. We performed a traffic analysis that shows this would have affected no customers in the last 90 days.