SteveB wrote:
> Here's the thing about open software that still concerns me. My
> background is with the major software development tools companies, so
> that is my point of reference. It is great that code is available and
> fixes are made and pushed out, but who is doing real testing of these
> fixes. Sure the obvious problem is fixed, but what other problems has
> it uncovered, what side effect has it created, and how about
> compatibility with other software or drivers in this case.
>
> With commercial software (well at least the places I worked) nothing
> could go out the door without a complete QA cycle performed on it.
> Even the smallest of bug fixes couldn't be released without a QA
> cycle. A full QA cycle was time consuming and expensive, so fixes sat
> until there was a stack of them to QA'd as a group or they had to wait
> until next upgrade. That way we knew state of the product. Yes, the
> state of the product would include known bugs. The key was a known bug
> and a known documented bug was as valuable as a fix. Sure a bug is
> bad, but if it is documented you don't waste trying to make something
> work that is known to be broke.
>
> So who is testing these fixes in open source world? Just seeing if
> the problem at hand is gone isn't real testing, even claiming
> thousands of people are now using it isn't enough. There can still be
> lurking potentially data destroying bugs lurking. In the open source
> world is there a official QA process or group. Is there a FreeBSD
> test suite that releases go through. QA is unglamorous work, but
> needs to be done.
>
> Steve B.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Wes Peters
> > Sent: Thursday, December 21, 2000 12:28 AM
> > To: Michael C . Wu
> > Cc: Dennis; Boris; Murray Stokely; [EMAIL PROTECTED]
> > Subject: Sitting on hands (no longer Re: FreeBSD vs Linux,
> > Solaris, and
> > NT)
> >
> >
> > "Michael C . Wu" wrote:
> > >
> > > On Tue, Dec 19, 2000 at 11:43:17AM -0500, Dennis scribbled:
> > > |
> > > | case and point: How many of us are sitting on our hands
> > waiting for DG to
> > > | have time to fix the latest snafu in the if_fxp driver?
> > You cant blame him
> > > | for having a job and earning a living, but the fact is
> > that only he has
> > > | enough experience with the part to do the job. We all
> > have source, but who
> > > | wants to spend a couple of weeks learning the
> > intricacies of a very complex
> > > | part to fix what amounts to a very small bug?
> > >
> > > Many of us do.
> >
> > I, in fact, once did. It was a great learning opportunity
> > for me and only a
> > minor pain in the butt for DG. I collected data and
> > learned where the driver
> > hung, he realized almost immediately what was causing the
> > problem and sent me
> > a quick pointer to aonther driver that already had the same
> > problem sovled,
> > and it took me another few minutes to isolate the code,
> > test, and provide a
> > patch.
> >
> > It is a shame how many think they cannot be of help in a
> > situation like this,
> > when in reality they can be extremely helpful. One of the
> > most important
> > skills you can learn and polish as an open source
> > contributor is to write
> > good bug reports or descriptions. Instead of saying "your
> > driver don't work
> > with my xyz123 rev A-11 card", say "the card initialization
> > enters the loop
> > in xyz123.c at line 413 (rev 1.4.2.27) and never returns;
> > if I change to the
> > to exit after 1 million tries, the system boots but the the
> > xyz123 device
> > isn't in the dmesg." Then include the full dmesg and
> > perhaps your kernel
> > config if that might have something to do with it.
> >
> > You'd be astonished just how helpful you CAN be, simply by
> > tracking down an
> > appropriate routine, adding a few printfs, and isolating
> > where the problem
> > is occurring.
> >
> > --
> > "Where am I, and what am I doing in this handbasket?"
> >
> > Wes Peters
> > Softweyr LLC
> > [EMAIL PROTECTED]
> > http://softweyr.com/
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
Please tell me this again. My experience lots of bugs go out the door.
Finding them is not easy. Some had dangerous secuiry flaws missed until
one playing around with logs a lot and tries all sort of strange things
somethings one ins't supposed to. One had an FTP secuirty flaw allowing
multiple retests of password. That and a good dirctionary attack and one
could drive the proverbial mack truck through. The Machine I trested had
a good easy to remember but mixed langauage pawword so multiple attacks
via dictionary showed in the log as about 500 attempts at root login w/
eventual failure. If the password tried on a dummy account (say Jay
Random) with the Japanese Password "Shashin" (meaning photograph showed up
surprisingly after 1111 tests. Common Error such as girls or boys names
were like 10 tries at most and many passed the "logging in drunk" test of
45 successive attempts. Those was on a well distributed Commercial
Production that had supposedky c-2 Security. It seems to me that from what
I have seen FREEBDS and Linux performed better than tthis.
Thanks for listening to my verbosity...
Have Fun,
Sends Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
