Thu, 11 Feb 2010
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 bts.turmzimmer.net 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 ;)
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:
|Unfixed bugs remaining in Squeeze:||424|
Of these 424 bugs...
|... are pending||32|
|... 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 (
hintmeans a package is forcefully migrated from sid to squeeze without waiting the usual time span)
- 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.