Bugs overview pages for Debian Pure Blends

To give users some overview about bugs that might concern a ?DebianPureBlend some pages listing all bugs of packages that are in the list of dependencies of a metapackage are generated. Here are links to this pages:

Motivation for the bugs pages

The main motivation for Debian Pure Blends is that there is a need for some substructure in the large flat package pool of Debian. This should be done based on user interest and needs and so every Blend should be an entry point for a specific user group into the large world of Debian. A specific user group is interested in a specific set of packages and consequently they might care more about the bugs of these packages than in any random package. How should users be attracted to have a look into this very specific package bugs?

The answer are these bug pages. Assume you are a mathematician and have some time to spend on bugs inside Debian. Where would you like to start seeking where to spend your time best? It should be helpful for both: For Debian and for you personal work and you should feel competent about the package you want to work on. Since today the answer is simple: Go to Bugs page of Debian Science for mathematicians and watch for bugs. On top of the page you see the note:

so your help is obviosely welcome. You also see immediately that there are two serious bugs in packages which are in the list of dependencies (not only suggested) of science-mathematics. So you found your targets quickly.

The Bugs pages are not (yet) internationalised. It is not decided yet whether this is really needed. The general scope of Blends is clearly to provide as much internationalised information as possible - so the strictly user oriented Blends/TasksPages contain as much translations as possible. But if the target audience for the bugs pages are people who should fix those bugs they have to understand the bug report in English language anyway. So people unable to understand the navigation might probably be not able to work on the bugs.

Realisation of the evaluation of bug status

The bug pages contain a way to measure how much help is needed for the dependencies of a metapackage. This measure is not about the quality of a metapackage because this would require a normalisation according to the number of packages. For instance a metapackage with 5 bugs in 25 dependendent packages is probably of a better quality than a metapackage with 3 bugs in 5 dependant packages. But I think we should care about the absolute number of bugs if we want to attract people who are willing to fix them and not about making some ranking inbetween metapackage quality.

Moreover bugs in packages that are in the list of Depends and Recommends should be weighted higher than those packages which are only suggested. This is reflected in the fact that the dependent packages are listed on top in a separate list. Below is a list of suggested packages. The bugs which are done are listed as well for historical reason - but they do not influence the bug status of the metapackage - done bugs do not need to attract our attention that much.

The evaluation is done by finding some weighting numbers for the different severities ranging from 10 for the RC bugs until 0 for wishlist bugs (see the currently used numbers in the footnote on the bottom of each page). Wishlist bugs are weighted with 0 not because wishlist bugs are not very interesting. Every bug should be fixed - but it might be a very rare situation that on one page might be only bugs with severity wishlist and so chances are quite low that wishlist bugs are just overlooked because there is no mark on the index page to visit this page.

These weighting numbers are multiplied by 3 if the package in question is a dependent or recommended package to reflect their higher importance. For example on the Linguistics page of Debian Science (status November 6, 2008) there are:

1 serious bug in a dependent package:

 1*10*3 = 30 

2 important bugs in a dependent package:

 2* 5*3 = 30

1 normal bug in a dependent package:

 1* 3*3 =  9

1 minor bug in a dependent package:

 1* 1*3 =  1

weighted sum =


On the index page you have a legend about the evaluation parameters: 72 > 50 (for "pass") which makes the coloring red for this package. Fixing the serious bug would make the weighted sum 42 which would bring the metapackage in the next better category "satisfactory" (< 50).

In other words: A metapackage can not be in status "good" if there is at least serious (or higher) bug in a dependant package. It also can not be "very good" if there is a RC bug in a suggested package - but two RC bugs in suggested packages might qualify for "good" - if there are only a very view other bugs which sounds quite improbable. Only one normal bug in a dependent package and no important bug in a suggested package do qualify for "excellent" - so this is really hard to reach.

These numbers might be discussed and in principle it is possible to make them configurable per Blend in the according webconf file. This is just a quick shot. For the moment I think it works somehow.