unfrozen repo somewhere?

[Les Mikesell]

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