Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.std.c
Subject: Shipping bogus code (was: Re: prototypes required ?)
Message-ID: <18632@rpp386.cactus.org>
Date: 23 Oct 90 14:20:40 GMT
References: <14164@smoke.BRL.MIL> <2150@lupine.NCD.COM> <27066@mimsy.umd.edu> <2173@lupine.NCD.COM> <27098@mimsy.umd.edu> <1990Oct22.231028.24623@zoo.toronto.edu>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Followup-To: poster
Organization: Lone Star Cafe and BBS Service
Lines: 23
X-Clever-Slogan: Recycle or Die.

In article <1990Oct22.231028.24623@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>Considering the number of things in (to pick purely random examples :-))
>SVR4 and SunOS 4.1 that clearly were never tested, I fear Chris is being
>naive.  Would that it were not so.

I think Henry is being equally naive - if a vendor were required to fix
every last bug prior to shipping a new release, we'd still be running on
ENIACs.  I constantly struggle with my current client trying to force
more fixes into the latest release, only to be told that the release
has to be shipped some day and that the latest bug I found doesn't merit
holding an entire release.

And of course some things just never get tested because the vendor would
rather forget they even have the code.  The "ged" command comes to mind
as one example.

There is more to shipping product than finding bugs and fixing bugs - one
must eventually decide it's soup and send it out to the masses.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson