Most of the code was written for private projects and I am not sure if I can show that code publically; though I can show it on request.

The project is to create a Debian Metrics Portal, a portal, that will be a central place for various metrics and stats. The portal will:

  1. Perform measurements by itself, from various sources and by different ways;
  2. Collect ready-made stats from various places;
  3. Display collected data in various ways (in text, in plots)

What is required to describe when creating a new metric

The author of the script decides by himself how and where to store the data.

For remote measurements

Why give so much freedom

There can be many use cases of how statistics is displayed. Examples:

And they all belong to Debian Metrics Portal.

Though not all metrics are complex and require so much freedom. An access to so many possibilities could be given by portal administrator only.


Django templates

Graph creating

One of the main features of the portal will be an easy way to plot data. The metric author should not care how to graph, only what can be graphed.

It means:

A template tag should handle it all. It will:

Plotting library

Flot will be used as a default plotting library. Flot is a pure ?JavaScript plotting library for jQuery, with a focus on simple usage, attractive looks and interactive features, used by many projects. Using it will allow to easily build graphs and add new metrics, getting them via Ajax.

Some users might want to share a hotlink to the graph image. An url to the graph image, plotted by matplotlib, will be generated for each change made in Flot plot, like adding a new metric to the plot, zooming etc.

If JS is disabled in the visitor's browser, a default version, generated by matplotlib, will be shown, with controls allowing to change metrics on the plot, zoom etc, but a reload of the page will be required for each action. Time and design permitting, the possibilities of this fallback version will be done as close to the JS version, as possible.


Django cache framework will be used for caching. Preliminary, caching might be required in interaction between the portal and user-provided scripts.

The metrics can be pretty simple. For example, a dependency of number of bugs from the date can be represented as a simple list of dicts. For these cases a more generic approach can be used.

A simple metric

This data will be saved in an inner table; the script author does not need to care, where to save his measurements.

Some other notes