Interpretare i numeri dei bug critici propedeutici al rilascio di una nuova versione di Debian

Alexander Reichle-Schmehl che monitora quotidianamente il numero dei bug che affliggono Squeeze, ha inserito nel wiki Debian la via di come leggere i vari numeri dei bug.

Interpreting the numbers of the release critical bug statistics

Contrary to the official bug tracker, the unofficial release-critical bug tracking tool at http://bts.turmzimmer.net/details.php to browse and filter release critical bugs in a more flexible way. Doing this can help us, to get a clearer picture of an upcoming release.

Using that interface one can for example filter release-critical bugs by different distributions. For example it currently lists 477 release-critical bugs in total for any distribution, but if you filter for release-critical bugs affecting squeeze, you get only 378. That's a different number as the official bug tracker shows; I'm not entirely sure why, but a part of that difference is that both the official and the unofficial web pages are only synced periodically.

But let's play more: You can filter for bugs valid in squeeze-only, but not in sid. These bugs are already fixed in sid, but the packages haven't yet migrated to squeeze. Currently that are 72 bugs. We can furthermore ignore bugs only in sid; when squeeze is unaffected, we just don't migrate the broken package from sid to squeeze. The number that is most interesting for contributors is the number of bugs affecting both, sid and squeeze, as these are the ones which really need to be fixed as no fix is known, yet.

So filtering for bugs for both we are down to 306 at the moment.

But of these 306 remaining release critical bugs, we can still ignore some (for now). For example bugs concerning packages in non-free or contrib (13 currently) won't stop us from release, will they? There are also many bugs marked as pending (16), meaning that the maintainer is aware of the bug has a fix prepared and is just waiting with the upload a moment. Some of this bugs have already a patch (46), but no one reviewed it and uploaded it by now. You'll also see that you can ignore merged bug reports (37). That are bug reports reporting the very same bug several times. Finally there are bug fixes already uploaded to the so called "delayed" queue. This are bug fixes which where uploaded by someone else than the real maintainer, but to give the maintainer a chance to act on himself or to comment, the upload is delayed by some days before it will actually hit the archive. Currently 7 bugs are fixed by uploads to delayed. 3 bugs are "claimed" meaning that someone already said he will take care of this bug (but they are not finished, yet).

And one can ignore security related bugs, too (29). The bad thing is, that this number will never hit 0, as security problems are detected all the time and thus these bugs came in all the time. The nice thing is, that they can be fixed after the release via a security update, so we can (more or less) safely ignore them for our statistics, too.

You could also ignore the bugs invalidated by today's britney bug category, representing bugs which will vanish after the next migration of packages from sid to freeze, but as we are only looking at rc bugs in both sid and squeeze, this number will always 0 ;)

That leaves "bugs somehow other marked as fixed" which are bugs (27) where I honestly have no Idea what they are... If someone can explain them, please do so ;)

Here is a small tabular showing the above numbers:

In Total:

477

Affecting Squeeze:

378

Squeeze only:

72

Remaining to be fixed in Squeeze:

306

Of these 306 bugs, the following tags are set:

Pending in Squeeze:

16

Patched in Squeeze:

46

Duplicates in Squeeze:

37

Contrib or non-free in Squeeze:

13

Claimed in Squeeze:

3

Delayed in Squeeze:

7

Can fixed in a security Update:

29

Otherwise fixed in Squeeze:

27

Or in other words: Release critical bugs left in "squeeze", when ignoring all these: 171

That's a pretty number, isn't it? There are only 171 bugs left which need our immediate attention :)

But that is a rather optimistic view of the situation. We e.g. assume that all bugs having a patch are really fixed by the patch. We also ignored, that some bugs in squeeze are already fixed in sid, but the package can't migrate because the package in sid contains a new bug, which seems to happen quite often.

So if we take off the purple classes and take a more pessimistic view (release mangers must be pessimists to ensure high quality packages ;) we count the bugs in squeeze and ignore only those bugs, which are:

* hinted / delayed upload ("hint" means a package is forcefully migrated from sid to squeeze without waiting the usual time span)
* merged
* contrib
* non-free
* bugs invalidated by today's britney (fixed in sid, package will migrate soon)

With this release managers views, 280 bugs remain to be fixed somehow before we can release.