Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
Just a comment on this... I used to work for a pretty big Unix OS vendor in the operating systems development group. 90% of the bug fixes I applied were never found by the QA group (otherwise they would have been fixed long before I ever worked there :-). Where they really found problems were cross-platform problems. E.g. I committed a change, tested it on platform X Y and it worked just fine. It failed to build on legacy platform Z. Building and testing on platform Z was near impossible, so as a developer, unless you were actually fixing a problem for platform Z, you never did it. After being bit a couple of times, I automated a script that did the cross-build, and never got bit again, but most people didn't do that. Heck, a major part of the QA group was dedicated to making sure the documentation was correct (not a bad thing, but it didn't help the actualy state of the software). Our -current works pretty much like the QA we had at this company. Most machines ran what we call -stable. All development machines (and there were a lot) ran -current, and a few ran a couple of releases back, just in case we had to fix something in that release. Knowing how many people actually run -current, I would say we have better testing than the OS company I worked for. Even though we don't have a real "QA" dept. -Mike On Thu, Dec 21, 2000 at 09:48:44AM -0800, 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. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
SteveB wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Wes Peters Sent: Saturday, December 23, 2000 11:29 PM To: Drew Eckhardt Cc: SteveB; [EMAIL PROTECTED] Subject: Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT) Drew Eckhardt wrote: commercial companies have formal QA staff because their development staff either can't or won't do the QA themselves. Developers shouldn't do their own QA they will miss things. They are too close to the code. You need another set of eyes to check things out. Places I've been developer's had a White Box QA engineer to work with early on. They wrote the test beds, setup development environments, tested pieces as developed, and would do some of the debugging for the developer. White Box QA were usually future developers and it helped train them. Then as the projects take shape the Black Box QA testers come in to do their bam-bam thing simulating users. Then building install programs and managing beta and burning the official release disks. Do you really want developers to be involved in all that? A good QA team save everyone time to focus on their own jobs. The above can best be described as a nutshell plan for quality as a built in process, something every project should do. In our place, we substitute other developers for the "QA engineer". In most companies, QA engineers are simply developers who didn't quite make it anyways. Taking the time of valuable engineers is seen as too costly for the gains made. We have the luxury of not accounting for the costs, and so do it with the talented people we already have. Don't misunderstand me here, I am NOT labelling all Quality Engineers as incompetent flacks, but rather pointing out that most QA departments are filled with other than Quality Engineers. I used to work for a company that defined the most rigorous software quality standards and test plans ever devised, and I still admire their ability. Many of the techniques they encoded into MIL-STDs are practiced, mostly instictively, by various members of the BSD community. In fact, they would probably benefit from the expertise of BDE greatly. -- "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
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
On Sun, Dec 24, 2000 at 12:28:36AM -0700, Wes Peters wrote: isn't coming to the forefront: commercial companies have formal QA staff because their development staff either can't or won't do the QA themselves. I would not agree with that at all. Commercial companies have format QA because it makes a better product. Every FreeBSD 3.0+ and later all have embarrassing bogons because of poor testing (or last minute MFCs). In the HP-UX kernel lab they have testing harnesses that simply abuse the hell out of the subsystem being tested (and on a various range of machines). This type of testing would be hard for the single developer to do. I would *love* to see the same for the FreeBSD kernel. I really wonder if we (FreeBSD) would stand up to the same level of torture. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Wes Peters Sent: Saturday, December 23, 2000 11:29 PM To: Drew Eckhardt Cc: SteveB; [EMAIL PROTECTED] Subject: Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT) Drew Eckhardt wrote: commercial companies have formal QA staff because their development staff either can't or won't do the QA themselves. Developers shouldn't do their own QA they will miss things. They are too close to the code. You need another set of eyes to check things out. Places I've been developer's had a White Box QA engineer to work with early on. They wrote the test beds, setup development environments, tested pieces as developed, and would do some of the debugging for the developer. White Box QA were usually future developers and it helped train them. Then as the projects take shape the Black Box QA testers come in to do their bam-bam thing simulating users. Then building install programs and managing beta and burning the official release disks. Do you really want developers to be involved in all that? A good QA team save everyone time to focus on their own jobs. Steve B. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
SteveB wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 21, 2000 9:54 AM To: [EMAIL PROTECTED] Subject: Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT) 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. I don't know about the "official" process, but I will tell you that I'd rather have my life depend on FreeBSD-current than on Windows NT, despite the "QA cycle". There are many ways to do effective QA. -s It would just make pitching FreeBSD and other open OS's in the enterprise a lot easier if there was an QA process that official releases went through. Also volunteering to QA would be a good training ground to gain familiarity with a OS and a chance to communicate with developers. By the way, there is some QA activity going on for Linux-64. Not that it's going too actively but may be worth looking at. The [weak] backbone of Linux-64 testing is SCO/Caldera porting the UnixWare test suites to Linux, so you may want to look at this stuff. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
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
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
In message [EMAIL PROTECTED], "SteveB" wri tes: With commercial software (well at least the places I worked) nothing could go out the door without a complete QA cycle performed on it. Yes. This is why the open systems have "releases" every so often; a release has been run through something more like a QA cycle. The QA cycle is where the naive fools run "-current" believing it will have "new features". :) 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. But you can't *do* anything. Imagine a known bug "doesn't run on Pentium or later systems". That's pretty much totally crippling now. The important point is that you get the choice. You can run a stable release, with known bugs, or you can run slightly less tested code which fixes them. 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. Yes. But that's just as true of a full QA cycle. Safety, in software, is an analogue signal, not a digital one. My experience (and I admit, I'm mostly from a NetBSD background) is that -current releases are dramatically more reliable, and less buggy, than commercial software. Testing, alone, does not catch bugs. *Analysis* does, and one of the things the open source community shines at is having a fix *analyzed* by a number of people. 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. I don't know about the "official" process, but I will tell you that I'd rather have my life depend on FreeBSD-current than on Windows NT, despite the "QA cycle". There are many ways to do effective QA. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
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 tests. Common Error
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
In message [EMAIL PROTECTED], "SteveB" wri tes: It would just make pitching FreeBSD and other open OS's in the enterprise a lot easier if there was an QA process that official releases went through. There might be; I haven't looked. I am pretty happy with the results of whatever's being done now, so maybe the right thing to do is document it. ;) Also volunteering to QA would be a good training ground to gain familiarity with a OS and a chance to communicate with developers. True. One of the nice things about the BSD's is that, while anyone can develop code and contribute it, there's a certain amount of review it has to pass before it's actually *USED*. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
In message [EMAIL PROTECTED], admin@bsdfan .cncdsl.com writes: 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. In a past life, I did half the design and implementation of the software tracking calls and letting the billing software know about them on a CDMA cellular base station. For hardware, we used machines from the biggest workstation vendor with a three letter name, running the latest production release of their Unix. Before booting the putz from our team who'd crippled our software with threads and excised the damage he'd done, we regularly dumped the machines out to the ROM monitor. I know people who work in several operating systems groups at that company, know a bit about their quality control process, and know that it was insufficient. I've yet to encounter a bug of that severity in any released version of free software (about the worst which wasn't hardware related is the FreeBSD Tulip driver not working correctly in full-duplex 100baseT mode). So who is testing these fixes in open source world? Cygnus is/was doing automated regression testing on GCC. 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. In theory, a standard suite of white and black box tests should be superior. Given inumerable bad experiences with Adobe, IBM, HP, Microsoft, Sun and other smaller companies, in practice it doesn't seem to work any better than the million-monkeys approach. QA is unglamorous work, but needs to be done. Does this mean you're volunteering? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
-Original Message- From: Drew Eckhardt [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 21, 2000 12:15 PM To: SteveB Cc: [EMAIL PROTECTED] Subject: Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT) In message [EMAIL PROTECTED], admin@bsdfan .cncdsl.com writes: QA is unglamorous work, but needs to be done. Does this mean you're volunteering? I don't have a lot of time, but I would volunteer if there was a QA project. I think it would be a good learning experience. Steve B. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
SteveB wrote: -Original Message- From: Drew Eckhardt [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 21, 2000 12:15 PM To: SteveB Cc: [EMAIL PROTECTED] Subject: Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT) In message [EMAIL PROTECTED], admin@bsdfan .cncdsl.com writes: QA is unglamorous work, but needs to be done. Does this mean you're volunteering? I don't have a lot of time, but I would volunteer if there was a QA project. I think it would be a good learning experience. One of the things I have been doing it cycling through 4 systems upgrading the userland and kernel. I have a script setup such that I capture everything from the cvsup log to build and installs. During the transition between 4.1.1-stable and 4.2-stable, one of this systems was updated everyday. It isn't a QA cycle that I experienced in the commercial world associated with the US Nuclear Regulatory Commission but it did insure that my setups work. If someone popps up on -stable and says that the "Buildworld is failing" for 4-stable, it is really easy to fire off that script and find out if it is. I have one running at this time. Kent Steve B. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
On Thu, Dec 21, 2000 at 12:40:22PM -0800, SteveB wrote: I don't have a lot of time, but I would volunteer if there was a QA project. Good QA takes time. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
On Thu, Dec 21, 2000 at 11:53:50AM -0600, Peter Seebach wrote: In message [EMAIL PROTECTED], "SteveB" writes: 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. I don't know about the "official" process, but I will tell you that I'd rather have my life depend on FreeBSD-current than on Windows NT, despite the "QA cycle". There are many ways to do effective QA. Yup. I think the important point here is that the formal QA cycle is a means to an end, but it's not the only way to achieve that end. I get concerned that those who point to a lack of a QA cycle in open source software are missing the point entirely: They're focussing on the 'process' they're familiar with so much that they don't seem to acknowledge that alternative approaches can demonstrate similar results. At the end of the day, the track record of major open-source projects speaks for itself: Yes, there are bugs, but there are bugs in commercial software which is shaped and bounded by QA procedures as well. Overall, though, I'd hazard a guess that open-source software is generally more reliable (it is in my experience, anyway). - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
Mark Newton wrote: I get concerned that those who point to a lack of a QA cycle in open source software are missing the point entirely: They're focussing on the 'process' they're familiar with so much that they don't seem to acknowledge that alternative approaches can demonstrate similar results. We open source zealots "know" this, but still it would nice to be able to point to some empirical data -- has anybody done a PhD thesis on it? If not, what are all the students waiting for? At the end of the day, the track record of major open-source projects speaks for itself: Yes, there are bugs, but there are bugs in commercial software which is shaped and bounded by QA procedures as well. Overall, though, I'd hazard a guess that open-source software is generally more reliable (it is in my experience, anyway). Again, that's the common experience, but it's easier to have the experience you expect when you're not constrained by facts. I'd love to see some good statistics. After all, open source people didn't get the chance to have the Ariane-5 disaster, so our ability to point to an empty set of such examples doesn't really prove anything. I'm a True Believer in the open source / free software gospel, but it would be easier to win these arguments if only we had the data. -- Greg Black ech`echo xiun | tr nu oc | sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
Greg Black wrote: Mark Newton wrote: I get concerned that those who point to a lack of a QA cycle in open source software are missing the point entirely: They're focussing on the 'process' they're familiar with so much that they don't seem to acknowledge that alternative approaches can demonstrate similar results. We open source zealots "know" this, but still it would nice to be able to point to some empirical data -- has anybody done a PhD thesis on it? If not, what are all the students waiting for? opensource quality depends on 2 things: 1/ the quality of teh original instigators. A bad design takes a lot to fix: 2/ the popularity of the project.. (to some extent) (and with who). The number of talented people with high enough interest needs to be greater than 1 and there are limits to how many such people there are.. (2 talented people with not a lot of time is probably less than 1 talented person with time) -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
It would just make pitching FreeBSD and other open OS's in the enterprise a lot easier if there was an QA process that official releases went through. Also volunteering to QA would be a good training ground to gain familiarity with a OS and a chance to communicate with developers. Steve B. This is a good idea. I wouldn't mind being involved in a program like this (volunteering for QA) if something can be organized.. Gilbert 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
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
* Gilbert Gong [EMAIL PROTECTED] [001221 18:45] wrote: It would just make pitching FreeBSD and other open OS's in the enterprise a lot easier if there was an QA process that official releases went through. Also volunteering to QA would be a good training ground to gain familiarity with a OS and a chance to communicate with developers. Steve B. This is a good idea. I wouldn't mind being involved in a program like this (volunteering for QA) if something can be organized.. What would extremely helpful would be a port that basically installed a bunch of utilities to stress the system into a chroot enviorment and ran a regression suite doing things like faking a large news server, serving a lot of http content etc. It would be helpful if the port was two parts, one for the test box and one as a client for the test box. Just some ideas for direction if you guys want to pick up the ball here. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
On Thu, Dec 21, 2000 at 12:03:23PM -0800, Gilbert Gong wrote: It would just make pitching FreeBSD and other open OS's in the enterprise a lot easier if there was an QA process that official releases went through. Also volunteering to QA would be a good training ground to gain familiarity with a OS and a chance to communicate with developers. Steve B. This is a good idea. I wouldn't mind being involved in a program like this (volunteering for QA) if something can be organized.. Join the freebsd-qa mailing list, and contribute some effort towards stress-testing parts of the system, developing regression suites, etc. A better FreeBSD release is up to you! :-) Kris PGP signature
