Horst H. von Brand wrote:
It's not the developer's fault that you _ship_ new bugs.
OK, packager's fault in that case then.
More realistically, the packager not having encountered the bug.
Just don't ship them.
If you have some sort of bug-detector that I can wave over packages before
letting them loose...
Large numbers of testers are the best way. There's nothing quite like
the real world.
You probably can't match RHEL's QA for free, but testing - and not
shipping things that don't pass - is the only way things can get
better.
Pray tell us, exactly how do we /do/ that? I think we all agree that that
is the ideal, but I strongly believe it is unatainable in pratice.
The big problem for me is that it's a package deal. I wouldn't mind
beta testing a few apps at a time on my working system with a stable OS
and libraries, but to run them you also have to take an experimental
kernel and device drivers. And my history with those on fedora is that
I waste too much time getting the hardware to work with new versions.
Maybe that's changed... If you had a way to separate the apps from the
OS, you might find people more willing to test the parts that interested
them.
I've heard the term used as in "an instrument's tuning is 'good
enough' for folk music" or "an approximation is 'good enough' for
government work". What's 'good enough' for an operating system?
Works mostly. Doesn't crash too often. Doesn't destroy valuable data except
under extremely unlikely circumstances.
Kernels that don't boot on machines where the last version worked or
lose the ability to access devices like firewire drives isn't 'mostly'
enough for me.
This is engineering, not mathematics. And even in mathematics there have
been mistakes...
But would you want to test a plane where the engineers said it was
probably good enough and didn't crash too often?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
