From owner-freebsd-hackers Thu Dec 21 9:48:10 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 21 09:48:04 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from warspite.cnchost.com (warspite.concentric.net [207.155.248.9]) by hub.freebsd.org (Postfix) with ESMTP id 5DB2A37B400 for ; Thu, 21 Dec 2000 09:48:04 -0800 (PST) Received: from buffy (w072.z064003114.lax-ca.dsl.cnc.net [64.3.114.72]) by warspite.cnchost.com id MAA22671; Thu, 21 Dec 2000 12:47:57 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Errors-To: From: "SteveB" To: Subject: RE: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT) Date: Thu, 21 Dec 2000 09:48:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A41BEFF.AC6E6CB9@softweyr.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: wes@FreeBSD.ORG [mailto:wes@FreeBSD.ORG]On Behalf Of > Wes Peters > Sent: Thursday, December 21, 2000 12:28 AM > To: Michael C . Wu > Cc: Dennis; Boris; Murray Stokely; freebsd-hackers@FreeBSD.ORG > 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 > wes@softweyr.com > http://softweyr.com/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message