On 2010-09-02 15:33, Justin B Rye wrote:
That, but some bugs in main packages can also be solved via removal. Some bugs in this category are filtered by the following tags: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. 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. 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.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. |