On Mon, Sep 13, 1999 at 06:17:37PM +0300, Antti-Juhani Kaijanaho wrote: > On Mon, Sep 13, 1999 at 06:59:39AM -0400, Michael Stone wrote: > > People keep uploading new > > packages with RCB's, and the RCB list keeps growing, regardless of how > > many RCB's are closed. > > No, the problem is not in new packages or in the number of opened RC bugs. > the problem is that too few RC bugs are closed! "Too few" is a pretty vague number. What is your accepted rate of bug closings? I maintain that bugs are being closed, but new bugs are being introduced just as rapidly. Let's look at the current stats. According to http://master.debian.org/~wakkerma/bugs/ for Sep 12, we opened 3 new bugs and closed 1. The bugs that were just opened were for ascd, octave, and realplayer. Octave had a recent upload that broke things. The realplayer bug is basically a gripe and is caused by the fact that we don't have a standard routine for installer scripts. (Everyone's trying to handle the potential security problems in different ways.) The ascd problem falls into the "who cares" category. (That is, if no one wants to fix it the distribution isn't going to suffer too much if it gets removed.) So the "sky-is-falling" contingent has three more Release Critical Bugs (caps manditory) to point to, but the integrity of the distribution is basically unchanged. I think of this as "bug inflation." As the number of packages in the distribution grows, it is unreasonable and impractical to try to keep the number of bugs constant. It is also impractical and unreasonable to both allow every package to have an equal impact on the RCB metric and to pretend that the RCB metric is a valid way of determining the state of the distribution. Let's look at this another way, and try to pick out the real RCBs (bugs in packages that most people would consider to be fairly fundamental.) apt -- broken in recent update base-passwd -- this one does need to get fixed bash -- fixes are provided for all outstanding bugs boot-floppies -- we know where this stands bsdmainutils -- seems to have a fix cron -- fix is provided debian-policy -- mail locking should get resolved dhcp -- solvable by fiat dpkg -- we've never made these bugs release critical before... dump -- this should get fixed e2fsutils -- integrate provided patches fetchmail -- needs a fix fileutils -- integrate patch, fix problem libc6 -- as with dpkg... perl-5.005 -- needs a fix tcpd -- integrate patch util-linux -- hwclock is a mess shellutils -- actual problem with date sysklogd -- needs to be closed I may have missed a couple, but the point remains: other than the packages listed above, none of the other so-called Release Critical Bugs is really release critical--the affected packages can be removed or the errata documented or somesuch. Of course that would upset the people using the buggy packages, but this is an open source project and anyone can fix the bugs. If no one considers the bugs in a package important enough to fix, why should they hold up the release of a couple thousand other pacakges? Disregarding boot-floppies (as that's almost a whole seperate project), dpkg (which never gets fixed) and libc6 (which needs upstream help and isn't realistically going to be removed) I count 7 packages with fixed or trivially-fixable bugs, 7 that need real work, 1 policy issue, and 1 bug that was just introduced in a new upload. I'd say we're doing pretty well. I'd be a lot more receptive if someone said "get some working boot-floppies and fix the seven deadly bugs so we can freeze" than I am to "we have 457 RCB's that must be closed before we can freeze." One is a realistic goal, one is a fantasy. Mike Stone
Attachment:
pgpAWoAya6t2X.pgp
Description: PGP signature