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

Re: DPN RC bugs statistics

On 2010-09-02 15:33, Justin B Rye wrote:
Filipus Klutiero wrote:
Justin B Rye wrote:
Alexander Reichle-Schmehl wrote:
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, [..]".
That's getting a bit tangled.  You mean

   Ignoring multiply reported bugs and ones which are easily solved
   or on the way to being solved, roughly speaking, about XXX release
   critical bugs remain to be solved for the release to happen.

Could "bugs which are easily solved or on the way to being solved"
be simplified to "ones that have a fix available"?
Not exactly, since "solving" a bug is not always "fixing" it. For  
example, the presence of a serious bug in a non-free package can be  
solved via package removal.
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')

      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. 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.

    Reply to: