[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Project News 2010/10 frozen. Please review and translate



 On 2010-09-02 04:48, Alexander Reichle-Schmehl wrote:
Hi!

Am 24.08.2010 21:11, schrieb Filipus Klutiero:

Thank you Alexander, here are my remarks:
[ where fixed before sending the issue out ]

According to the<a
href="http://bts.turmzimmer.net/details.php";>unofficial
     release-critical bug counter</a>, the upcoming release,
     Debian 6.0<q>Squeeze</q>, is currently affected by
302 release-critical bugs. Ignoring bugs which are easily solved
     or on the way to being solved, roughly speaking, about
128 release critical bugs remain to be solved for the
     release to happen.
Assuming this is valid as of August 20 (based on
http://blog.schmehl.info/Debian/rc-stats/2010-33 ), the high number is
wrong. It counts duplicate bug reports. These need to be ignored by
checking the "merged" checkbox (although clearly, it's a problem of the
RC bugs count that duplicates are counted, even by default). As of now,
the high number should be 262.
Ah, I think that was introduced recently, when the paragraph was
rewritten.  Maybe it should be more something like: "The [bts] currently
knows about 302 release-critical bug reports.  Ignoring bugs multiple
reported bugs, bugs which are easily solved or on the way to being
solved, [..]".
The problem is not so much in the formulation, it's just in the high number itself. We should avoid referring to bug reports, BTW; what matters is bugs. We can talk about reported bug though, to emphasize some bugs are not reported and not counted. The problem is just the "merged" checkbox needs to be checked when getting the counts, otherwise we count duplicates. For example, right now, the high number should be 267. However, if I forget to check, I get 289, which is significantly off.

BTW: I have been told, that basing the numbers on the unofficial bts
leads to wrong numbers, because of several bugs in the code behind
bts.turmzimmer.net.  So sooner or later, the script creating the stats
should be rewritten to get the numbers directly from the bts.  (To the
best of my knowledge via soap?)
Hum, I wasn't aware of that. I verified the count semi-manually. Checking the low number, I confirmed the current 125 counting the bugs displayed:

$ grep '">[1234567890]*</a>' details.php |wc -l
125

If there is a problem, it might be in the filtering of bugs. That would be much more important to fix than a wrong count, and deserve a proper fix (in particular if some bugs that should show do not).


Reply to: