Thu, 11 Feb 2010

[Update 2] RC-Bug statistics for Squeeze, calendar week 6:

Back in the Lenny release cycle, I published some statistics of the release critical bugs. As we are (try to) get nearer to a freeze of Squeeze I think it's time to start that again.

But first, a small explanation follows, what these numbers actually mean. If you look at our official bug tracking system currently lists 750 release critical bugs affecting the next stable release. While this number is kind of true, it is not accurate to use it to measure the state of the release. The unofficial rc bug thingy at is quite more powerful to actual get some interesting numbers, as you can ignore specific kinds of bug and filter them properly. Note, that at the very end of the detailed list of the bugs you get the total number.

With that interface you can for example filter them by different distributions. For example it currently lists 650 rc bugs in total for any distribution, but if you filter for squeeze bugs, you get only 518. 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. Should someone be able to give a good explanation about the differences, please step forward ;)

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 94 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 424 at the moment.

But of these 424 remaining release critical bugs, we can still ignore some (for now). For example bugs concerning packages in non-free or contrib (9 currently) won't stop us from release, will they? There are also many bugs marked as pending (32), 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 (64), but no one reviewed it and uploaded it by now. You'll also see that you can ignore merged bug reports (47). That are bug reports reporting the very same bug several times. Finally there are bug fixes already uploaded to the so called delayed queue (6). 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 6 bugs are fixed by uploads to delayed. 17 bugs are claimed meaning that someone already said he will take care of this bug (but they are not finished, yet).

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 (39) 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:

Affecting Squeeze:518
Unfixed bugs remaining in Squeeze:424

Of these 424 bugs...

... are pending32
... are patched:64
... are duplicates:47
... are in Non-free or contrib:9
... are claimed by someone:17
... are fixed in the delayed queue:6
... are somehow marked as fixed:39

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

That's a pretty number, isn't it? There are only 260 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 happens to release wizard Marc Brockschmidt 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, 424 bugs remain to be fixed somehow before we can release. As far as I know, we can freeze once that number is reliable under 300. So we better get working ;)

When asked, what is the thing mostly needed to help the release, I was told: mips porter!
As you might have read we have some problems with the mips and mipsel architectures. It seems we have all the hardware we need, but it doesn't work very reliable. I have been told, that over 300 packages are only waiting to be build on mips* architectures. So if you can help us in that regard, please contact our mips porter mailing list.

Update: Andreas Barth just told me, that he already send a couple of mails to the mips list describing the problem and asking questions. Answers to these questions would be most welcome and accpeted gladly.

Update 2: Moritz Muehlenhoff just informed me, that I should also ingore RC bugs having the tag security for my statistics, as they come in all over the time and can always be fixed with a security update or in a point release.

postet at 13:49 into [Debian] permanent link


Alexander Tolimar Reichle-Schmehl lives in Tuttlingen / Germany. He works as IT manager (specialized on Unix and SAN/Storage) for an international automotive supplier.