unfrozen repo somewhere?
Les Mikesell
lesmikesell at gmail.com
Mon Sep 29 23:37:40 UTC 2008
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 at gmail.com
More information about the devel
mailing list