Xref: utzoo comp.lang.c:26533 comp.software-eng:3038 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcnc!rti!xyzzy!larrybud.rtp.dg.com!goudreau From: goudreau@larrybud.rtp.dg.com (Bob Goudreau) Newsgroups: comp.lang.c,comp.software-eng Subject: Re: C Community's Cavalier Attitude On Software Reliability Message-ID: <798@xyzzy.UUCP> Date: 3 Mar 90 22:00:55 GMT References: <8212@hubcap.clemson.edu> <7351@arcturus> Sender: usenet@xyzzy.UUCP Reply-To: goudreau@larrybud.rtp.dg.com (Bob Goudreau) Organization: Data General Corporation, Research Triangle Park, NC Lines: 44 In article <8212@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > If a currency conversion program is based on the exchange rates > as of a given date, then this is a continuation of the specification > which does not belong in the DEFECTS section. I see -- your latest strawman is that the manual page for units(1) does not conform to *your* idea of proper documentation format. Well, big f---ing deal. Many of us find it *helpful* to have caveats and bugs called out separately instead of buried in the "specification". ("It ain't a bug -- it's a *Feetchur*!") But I see your strategy -- your new attack draws attention away from your original complaint about units(1), which must have embarassed you horribly when you found out about floating (gasp!) currency exchange rates. > Under no circumstances should a DEFECTS section contain flippant > comments such as "I tinker a lot, so things break, but then I fix > them, hooray", "Not bloody likely", or other comments which indicate > a cavalier attitude toward software reliability. > > DEFECTS sections exist for the purpose of listing known areas in > which an implementation does not correspond to the specification, > along with potential workarounds (if any) and the estimated date > of repair. Now compare this with your typical Unix BUGS section. Well, I have, and except for the "estimated date of repair" part, I find that most UNIX manpage BUGS sections already seem to offer just this information. (BTW, the EDoR of a bug is *not* a documentation issues, a C issue, a UNIX issue, or even a programming issue. It's a product/release management issue. Only after an EDoR has been decided can it be documented.) As for your examples, the ones with "flippant comments" seem to be still more strawmen for your pathetic argument. What the heck is dab(1) anyway? Are you perhaps confusing manpages for a real product with manpages for locally programmed (and documented) extensions to the system? ------------------------------------------------------------------------ Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA