Re: DPN RC bugs statistics
Le 2010-09-03 15:06, Justin B Rye a écrit :
Philippe Cloutier wrote:
Justin B Rye a écrit :
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.
So this separates "bugs that need to be dealt with" from bugs that don't
need to be dealt with. It is true that one group needs less energy than
the other. It's true that bugs fixed in unstable are pretty much dealt
with, but it is quite a simplification if talking of bugs simply
claimed, affecting non-main packages, patched or pending.
It separates "the bugs that need to be dealt with *before* the
release can happen (by [a specific definition])" from everything
else. But okay, would it be better if it said "the bugs for which a
fix must be found before [etc]", or something like that?
That would fix the problem, but introduce another, that is the
implication that all bugs in the low number need to be "fixed" (although
some can be solved via removals too).
A strategic redeployment of weasel words might also help:
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 (roughly speaking) only the bugs
for which a fix must be found before the release can happen, by
the DPN's standard criteria[*], XXX bugs remain to be dealt with.
Meh, I don't know :-( For the first sentence, I would rather have:
According to the unofficial release-critical bug counter[*], Debian `Squeeze', which will become the next stable release, is currently affected by
XXX release-critical bugs.
I wrote my previous message under the impression that security bugs were
excluded from the high number (as well as from the low number). I see
this is not the case. I think this is incoherent. For the reason I wrote
in that message, most security bugs with release-critical severities are
not actually release-critical. It would be inexact to ignore them
completely, but less so than taking all of them into account.
This is an argument for changing the numbers, rather than the way
they're described, so I'll bow out here.
OK. I forgot to mention that not taking any security bug into
consideration will make the high number too low, but at the same time
this number is too high because it includes some non-security bugs
present in stable. So these 2 effects compensate each other to a certain
degree.
Reply to: