Re: DPN RC bugs statistics
Filipus Klutiero wrote:
> Justin B Rye wrote:
>> If the statistic we're trying to explain counts only bugs in main it
>> should probably say so less indirectly:
>> Counting only unique bugs affecting Squeeze main with no fix
>> available, roughly speaking, about XXX release-critical bugs
>> remain to be solved for the release to happen.
>
> That, but some bugs in main packages can also be solved via removal. Some bugs
> in this category are filtered by the following tags:
> Ignore by 'hinted / delayed upload': Ignore bugs that are either hinted (a
> Release Team member has decided this package is to be removed from testing, and
> it will get removed soon) or for which there is an upload in the 'delayed'
> upload queue (probably a NMU) already waiting to get in the archive.
> Ignore by 'claimed / assigned to ftp/qa': Hide bugs that are either already
> claimed to be working on by somebody else (claims page), or that someone asked
> for it to be removed ('assigned to ftp/qa')
I understand all this. My point is that the text is supposed to be
more than just technically true once you've worked through its more
obscure implications; it's supposed to be informative.
>>>>> What category are security-upload candidates meant to be in?
>>>>
>>> What do you mean? What category are security bugs meant to be in?
>>
>> To quote http://wiki.debian.org/ProjectNews/RC-Stats:
>># And we can ignore security related bugs as well (29). The bad
>># thing is that this number will never hit 0 since security problems
>># are detected all the time and thus these bugs come 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.
>
> If I understand correctly your question, security bugs are not taken into
> account in any number.
Yes; in other words, they're among the bugs that are being ignored,
but they aren't covered by any of the categories in the DPN's brief
summary of ignored bug types.
> This is in large part because most of them also affect
> stable, so releasing them would not be a regression. It would be nice to take
> security bugs in new packages into account, but I'd say I agree with the
> current stance, if the only alternative is to count all security bugs.
Of course. So if our aim is to produce a technically correct short
summary of what bugs are being ignored, we should use a summary that
covers *all* the categories of ignored bugs. Alternatively, instead
of trying to cram all this complex information into one sentence:
According to the unofficial release-citical bug counter[*], the
upcoming release, Debian 6.0 `Squeeze', is currently affected by
XXX release-critical bugs. Ignoring security bugs, multiply
reported bugs, bugs which are easily solved, and bugs on the way
to being solved, roughly speaking, about XXX release critical bugs
remain to be solved for the release to happen.
There are also more detailed statistics[*] as well as some hints on
how to interprete[*] these numbers.
the DPN could just say something like:
According to the unofficial release-critical bug counter[*], the
upcoming release, Debian 6.0 `Squeeze', is currently affected by
a total of XXX release-critical bugs. More detailed statistics
are also available[*]. Counting only the bugs that need to be
dealt with before the release can happen (by the DPN's standard
criteria[*]), roughly XXX bugs remain to be solved.
--
JBR - and today's single word in West Greenlandic is:
Tusaanngitsuusaartuaannarsinnaanngivipputit
"You simply cannot pretend not to be hearing all the time"
Reply to: