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

Re: DPN RC bugs statistics



 Le 2010-09-03 07:02, Justin B Rye a écrit :
Filipus Klutiero wrote:
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.
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.

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.


Reply to: