dhesi@bsu-cs.UUCP (Rahul Dhesi) (11/09/88)
In article <36085@clyde.ATT.COM> rcj@moss.UUCP (Curtis Jackson) writes: >In article <4648@bsu-cs.UUCP> W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) writes: >}Bug report:... In the interest of accuracy, I wanted to point out that comments within square brackets, usually with "-- R.D." at the end, are from the moderator and not from the person sending the program. While we are on the subject, here's something that I wonder about. If I find some shortcomings (ahem) in a submission, which of the following two alternatives is better? -- posting it and simply documenting bugs that I find -- or not posting it and sending feedback to the author and waiting for him to either fix it or ask me to go ahead and post anyway In the first case, I risk offending the author (e.g. "Why didn't you tell me instead of slandering me all over the net?") and possibly the user. In the second case I risk offending the author again, make more work for me, delay postings, and have the public scream "censorship!" to boot. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
malpass@vlsi.ll.mit.edu (Don Malpass) (11/10/88)
In article <4670@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > >If I find some shortcomings (ahem) in a submission, which of the >following two alternatives is better? > >-- posting it and simply documenting bugs that I find > >-- or not posting it and sending feedback to the author and waiting for >him to either fix it or ask me to go ahead and post anyway.... >In the second case I risk offending the author again, ... delay postings,.... I'd vote for the second, in spite of the added effort (easy for ME to say - it's YOUR effort). It feels more courteous to give the author the chance to select the first option. On a somewhat related subject, is there a permanent repository of names (perhaps with lengths, dates, crc's and other identifying characteristics) of programs that are KNOWN to be either viruses or trojan horses or otherwise contaminated? After last week's "conciousness raising" I think such a "history list of dangerous code" could be of value. I doubt that it would generate an undesirable challenge for somebody to get listed in "the top 10" out of some sick desire for notoriety. -- Don Malpass [malpass@LL-vlsi.arpa], [malpass@spenser.ll.mit.edu] The Malpass Principle: Given a binary choice, the statistical probability of doing the right thing is 31.7% - on good days.
frotz@drivax.UUCP (Frotz) (11/11/88)
In article <4670@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >If I find some shortcomings (ahem) in a submission, which of the >following two alternatives is better? > >-- posting it and simply documenting bugs that I find > >-- or not posting it and sending feedback to the author and waiting for >him to either fix it or ask me to go ahead and post anyway My vote is for: a) requesting information from the author on small packages. (If I were the author, I would want to know that something was wrong with my small(>20K) utility.) b) sending out bug reports on (>20K) medium to large packages. Frotz
rcj@moss.ATT.COM (11/15/88)
In article <4670@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: }If I find some shortcomings (ahem) in a submission, which of the }following two alternatives is better? } }-- posting it and simply documenting bugs that I find } }-- or not posting it and sending feedback to the author and waiting for }him to either fix it or ask me to go ahead and post anyway My vote -- send it back. Buggy programs can cause serious damage; usually in the form of data loss. They can also waste thousands of dollars in phone charges to people downloading useless software. Just because something is free doesn't mean its most basic functions shouldn't be tested. Rahul, if you can find bugs in just a cursory examination/run of a program, it obviously has not been tested well enough to inflict on the world. Curtis Jackson -- att!moss!rcj 201-386-6409 "The cardinal rule of skydiving and ripcords: When in doubt, whip it out!"