Sean Armstrong wrote:
> The point is the code WAS there to initialize the cdrom in mdk6.1 but it was
> lost in O2 and never recovered. There are many listed outstanding bugs at
> Mandrake that haven't been corrected yet and Mandrake shouldn't release this
> product under the guise of being stable if it isn't. I love mandrake just as
> much as thext guy, but I think Mandrake really has some QC/QA issues to
> address.
> Thanx,
> SA
Actually yours may not be one of them. They had to use a special kernel to run
the GUI install and they don't have your CD drive. The only alternative is a
drop-out to text mode *and * booting a different kernel. There are QA issues
to address, and there is NO system for QA that is likely to work on their
development model, which is why I want to recruit you and others to put
together a proposed system for it.... But get over the idea that this CD issue
of yours is a bug. Hardware gets left behind all the time.
Moreover, the idea of ALPHA and BETA again I say cannot apply to the open
development model they follow. Who thought of that, anyway, and what basis in
terms of data showing the eliminating of bugs did it have? We break new ground
in many areas when we step outsiode of classical models. Windows 2000 went to
production/distribution with between 28,000 and 63,000 known "bugs and issues"
depending on which source you get your data from. Now that is a lockstep in
the classical debug model or QC/QA model and we see clearly what the system
capability is. With nearly unlimited manpower and funds, that QA model is
STILL broken.
So back to square one... We have a fabulous assortment of tools and some great
ideas, but no systematic process that is appropriate to the situation. And the
classical ideas have no data supporting the output of quality software for this
development process, or for that matter data for the classical process either.
I have a strong suspicion that the classical QA process was the brain child of
a few academicians, established by logic and authority(of their illustrious
credentials), and taught by tradition since. I have not found much data at all
that it produces fewer errors or in fact has any significant impact on the
process capability for errors, just as most "inspection" schemes for quality
fail in any business. I steer clear of the airline that has a vice-president
for lost baggage, and I avoid the computer manufacturer that has a robust and
well-financed customer service department, because I see both working on the
wrong things. You don't have a super system to look for lost baggage, you set
up your system so it is very hard to lose it in the first place. You don't
have people fixing the hurt feelings and broken equipment of customers, you
build it right in the first place.
So, Sean, you seem to be slightly off the topic. Pointing to bugs and saying
BETA is no answer. Every software developmenrt imaginable has bugs and some
products have more, some less because it is a process and it is subject to
variation. And tampering within that process is likely to INCREASE the
variation, so that either fewer or more bugs appear. The proper approach is
select an area to redesign in the process; collect data; study results; and
freeze those things that prove, statistically, to be improvements, then select
another area to improve in how the software gets built. Now it takes
consumers, producers, and an occasional "wild duck" on a team to study
something like this, but it is worth it. Five years ago, it looked like all
Americans were going to be driving Japanese cars before the American auto
companies clued in to this process themselves.
Civileme
>
>
> >From: Brook Humphrey <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >Subject: Re: [expert] Formerly: Mandrake 7.02 is messed up
> >Date: Thu, 23 Mar 2000 09:35:58 -0800
> >
> >I've been watching this thing for a while and I'm also on the cooker
> >list helping the devel team. What I've noticed is this Pixel one of the
> >programmers is straight forward he tells you like it is and tries to fix
> >it if he can find the problem and he recently posted that they can't
> >recreate the problem. Now maybe if you send them your computer they
> >could recreate it and fix it. Otherwise how are they expected to have
> >every piece of hardware ever made in every configuration ever made or
> >put together in someone's garage? This is viable considering all the
> >different manufacturers out there. being on the cooker team I've seen
> >other things and like for instance at least you don't have a brand new
> >kenwood truespeed cdrom they do run allot faster but linux hates them.
> >I've also seen allot of older stuff working that windows won't even
> >touch because the drivers can't be found. I Own a computer store and you
> >would be suprised at what people are still trying to run.
> >
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
