Re: Debian Project News 2010/10 frozen. Please review and translate
On 2010-09-02 04:48, Alexander Reichle-Schmehl wrote:
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.
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
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
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
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?)
$ grep '">*</a>' details.php |wc -l
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).