I don't know why I'm bothering to answer, but the reason bugs will surface
in real use is that no matter how brilliant the testers are, they will not
think of everything.

> 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