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

Re: Deficiencies in Debian

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

Reply to: