From: Adam Flinton 

Ellen K. wrote:

> Don't be ridiculous.   Of course you test, you test everything you can
> think of and then some.   And then there will still be bugs in the
> initial release.
>

& following your assertion, in the subsequent release & the one after
that etc.etc.etc.etc.

Why do you think that simple useage will bring all bugs to the surface?


> A developer who claims his or her apps never have bugs reminds me of the
> saying of my late father (a lawyer) that the lawyer who's never lost a
> case has probably never tried one.
>

Yup & there will thus be bugs in the system period. Not just in the
"initial release". I wonder how long some of these IE bugs have
been around but just undiscovered?

Adam



> On Sun, 18 Jul 2004 11:13:55 +0100, Adam Flinton
>  wrote in message :
>
>
>>Ellen K. wrote:
>>
>>>Oh please.
>>>
>>>No matter how much you test, there will still be bugs in the initial
>>>release.
>>>
>>
>>In which case there will always be bugs in every release so why bother
>>to test?
>>
>>Adam
>>
>>
>>>On Thu, 15 Jul 2004 18:11:36 +0100, Adam Flinton
>>> wrote in message
:
>>>
>>>
>>>
>>>>Rich wrote:
>>>>
>>>>
>>>>
>>>>>  It may not be economical if testing is simply not
something that
>>>>>these folks care about.  The actual change is a tiny
part of releasing
>>>>>an update.
>>>>>
>>>>
>>>>Indeed. MS have to be masters of major updates as they have
to do it all
>>>>the time.
>>>>
>>>>However wrt testing the best time & place to do that is before it
>>>>becomes part of the product & not after it's been
released which is what
>>>>the openbsd people tend towards vs the marketing driven cycle in
>>>>evidence wrt MSOS'es.
>>>>
>>>>Adam
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Rich
>>>>>
>>>>>
>>>>>   "John Beamish"  wrote in message
>>>>>   news:40f69bc7{at}w3.nls.net...
>>>>>   (I'm not running Linux.)
>>>>>
>>>>>   I find that statement "economical with the
truth".  Assume that you
know
>>>>>   which module to go to.  Check it out, make the
change, check it in,
>>>>>   recompile it, do regression testing (assume the
change works and
doesn't
>>>>>   break anything), update module documentation, update
changelog, update
>>>>>   bugtracking.   In any serious environment, that's a
day's work -- not
an
>>>>>   hour.
>>>>>
>>>>>   What happens next?  Are Linux users expected to d/l
the recompiled
>>>>>   module or
>>>>>   is there a process to compare the previous version
with the new
>>>>>   version and
>>>>>   generate some kind of hex patch which gets
downloaded and applied?
>>>>>   Or what?
>>>>>
>>>>>   Thanks.
>>>>>
>>>>>   "Adam Flinton" >>>>   > wrote in message
>>>>>
>>>>>    > Security information moves very fast in
cracker circles. On the
other
>>>>>    > hand, our experience is that coding and
releasing of proper security
>>>>>    > fixes typically requires about an hour of work
-- very fast fix
>>>>>    > turnaround is possible. Thus we think that
full disclosure helps the
>>>>>    > people who really care about security."
>>>>>    >
>>>>>    >
>>>>>    > etc.
>>>>>    >
>>>>>    > Adam
>>>>>
>>>
>>>
>

--- BBBS/NT v4.01 Flag-5