Date: Thu, 21 Jul 2005 08:50:53 -0400 From: "MikeM" <the.lists@mgm51.com> To: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD Message-ID: <200507210850530519.03A3275D@sentry.24cl.com> In-Reply-To: <200507212029.47615.doconnor@gsoft.com.au> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/21/2005 at 8:29 PM Daniel O'Connor wrote: |On Thursday 21 July 2005 19:27, Marc Olzheim wrote: |> Thank you for expressing my exact same sentiments. I'm still a huge |> FreeBSD fan and switching to anything else (well, perhaps DragonFly) |> seems out of the question, but my faith is being tested a lot lately. |> Having switched some of my companies production machines to 5.4, since |> it was (in my eyes falsely) called a 'production release', FreeBSD's |> reputation within the less technical parts of the company has taken a |> large dent. Luckily they know as well that there's still no comparison |> to FreeBSD 4.x; top of my ruptime looks like: | |I think the best way to rectify this is to test RC candidates on YOUR |hardware.. This finds the bugs you need fixed at a time when people are |very receptive to fixing them. | |It's not realistic for the release engineer to test on a lot of hardware |as they are very busy doing other things. ============= Your comment presupposes that most of the bugs are specific to one piece of hardware, I doubt that is a valid assertion. I would offer that most of the bugs are not present in source code specific to a certain piece of hardware, but are present in source code that is run across much of the hardware that FreeBSD runs on. As such, it is just a matter of setting up the correct QA testing scripts to catch the bugs. Once a bug is reported, and that bug can be reproduced on the hardware of the development team, then that bug should not reappear again, because there should be a testing script written for it. Additionally, every software bug is not only a defect in the software, but it also represents a defect in the process that created the software. Bugs should be looked at to analyze why they occurred, and what in the process might be changed to prevent the same or similar bugs from recurring.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507210850530519.03A3275D>