Skip to main content

Mantis bug tracker statistics

Recently I published in Google code a project aimed at computing some statistics about the bugs contained in the Mantis bug tracker instance used in my office.

The project is here:

https://code.google.com/p/mantis-statistics

The project is composed of:

  1. the main application written in Python;
  2. a form written in PHP that integrates into Mantis GUI.

The application uses the bug history table to check which bugs have not been resolved by a user in due time. By "due time" I mean a duration in days that can be set in the application using the command line parameters. There are three possible durations associated to three different bug priorities: normal, high and urgent. If a bug has not been processed in due time depending on its priority I call it an "expired" bug.

There's also another concept to be explained, and it's what I call a "transition". A transition is when a bug changes status going from a start status to an end status. For example a transition is when a bug goes from the "assigned" to the "resolved" status. In the application you can select which is the transition you would like to check. So you can ask which are the bugs that haven't been transitioned from assigned to resolved in due time, or the bugs which haven't been transitioned from resolved to closed in due time, or a transition between two custom states you added to Mantis.

There are command line parameters to choose the due times, the transition to be checked, the user to be checked, and so on. The details are here:

https://code.google.com/p/mantis-statistics/wiki/Usage

Having chosen the user, the transition and the due times, the application is capable of two different outputs:

  1. a list of the expired bugs grouped by project;
  2. a statistic on the numbers of expired bugs grouped by project, year and month.

The list of expired bugs shows for each bug the id, summary, priority and days elapsed; in the HTML format you can click on the bug id to open the bug detail page in Mantis.



The statistics page shows a cell for each project, year and month containing two numbers: the number of expired bugs in the period and the total number of bugs.



Both reports can be output in various formats:

  1. ascii: suitable for a terminal output;
  2. html: this is the format used to display the output in Mantis GUI;
  3. html standalone: this is similar to the previous one but contains also the CSS definitions, and the links to Mantis bug detail page are absolute; this format is thought to be attached to a mail to be sent as a report;
  4. csv: it's a CSV format to be imported into spreadsheets.

I provide also a PHP form that integrates into Mantis GUI and that can be accessed as a custom menu item. The form drives the Python application using the same command line parameters you use in a terminal. Obviously the form can be customized at your will.

Comments

Most popular posts

Pairing the Raspberry Pi 3 with your Playstation 3 controller

While setting up the MAME emulator on the Raspberry Pi 3 I decided to experiment with the PS3 controller trying to pair it with the RPi. I found a useful guide here: http://holvin.blogspot.it/2013/11/how-to-setup-raspberry-pi-as-retro.html At section 4 the author describes how to compile sixpair utility, test that everything is working and compile the QtSixA tool. But there are some differences to be noted when working with the Raspberry Pi version 3. First, and most obvious, of all: the RPi 3 has already a Bluetooth device built in, so you don't have to plug a dongle in it, and it's compatible with the PS3 controller. 1. Sixpair The sixpair utility succeeds in coupling with the controller. But to test that it's working I had to test the js1 joystick port, and not the js0 as stated in the guide; so the actual command is: jstest /dev/input/js1 2. QtSixA The QtSixA download link must be changed, because the one shown doesn't compile with the latest

JSON Web Token Tutorial: An Example in Laravel and AngularJS

With the rising popularity of single page applications, mobile applications, and RESTful API services, the way web developers write back-end code has changed significantly. With technologies like AngularJS and BackboneJS, we are no longer spending much time building markup, instead we are building APIs that our front-end applications consume. Our back-end is more about business logic and data, while presentation logic is moved exclusively to the front-end or mobile applications. These changes have led to new ways of implementing authentication in modern applications. Authentication is one of the most important parts of any web application. For decades, cookies and server-based authentication were the easiest solution. However, handling authentication in modern Mobile and Single Page Applications can be tricky, and demand a better approach. The best known solutions to authentication problems for APIs are the OAuth 2.0 and the JSON Web Token (JWT). What is a JSON Web Token? A JSO

Software Release Management For Small Teams

Formalizing The Release Management Process (If There’s Any) In some team configurations, especially ones that are found in startups, there are no DevOps, nor infrastructure engineers, to provide support when releasing a new version of the product. Moreover, unlike large bureaucratic companies with defined formal processes, the CTO or Head of Software Development team in a startup is often not aware of the complexities of the software release management process; a few developers in the company may be aware of the complex details of the process, but not everyone. If this knowledge is not documented thoroughly , I believe it could result in confusion. In this article, I’ll try to provide some tips about how to formalize the release process, particularly from the developer’s point of view. Enter The Software Release Checklist You may be familiar with the idea of a checklist for some operations, as per the Checklist Manifesto , a book by Atul Gawande. I believe a formal release proc