Yum broken = no testing

[Russell Coker]

On Friday 26 November 2004 18:51, Sean Middleditch <elanthis at awesomeplay.com> 
wrote:
> > > so by that argument, if gtk had an api break then mozilla should work
> > > around it, rather than making the fix occur in gtk?
> >
> > Yes. That's how things work in real world.
>
> No.  No, it is not.  In the toy development system world, maybe.  In the
> real world, major system libraries like GTK and Python remain ABI and
> API stable.  If a breakage does occur, the breakage is separated into a
> new major version allowing both versions to be installed.  GTK in fact
> makes that guarantee, and that is one of its biggest selling points.

In what world are APIs really stable?

Some people who use an OS other than Linux have problems with shared object 
versions where several applications from the same vendor ship different 
versions of the same shared object that conflict.  On that OS you were 
required (last time I programmed for it - which was fortunately a while ago) 
to rename the libc shared object if you wanted to have it dynamically linked 
into your applications.  This meant that several applications from different 
vendors would have different versions of the libc which all came from the OS 
vendor!

In the Linux world we are way better than that!

> > As a developer you spend a significant time to work around bugs, API
> > changes and things which don't behave as you expect them to do.
>
> That's not an excuse.  That's a description of all that's wrong with the
> world from a programmer's perspective.  ;-)  Bugs are going to happen,
> but there is absolutely *no* reason for an API/ABI breakage, ever,
> without at least versioning the break correctly.

The real issue is, given that the API has broken and systems have broken as a 
result, what shall we do about it?

Beta testers are very valuable.  We don't want to burn them so badly that they 
give up testing!  If we have to release a hacked-up version of an application 
to allow recovery from a broken ABI as an interim measure then that's not a 
problem IMHO.  I think that the priority in this situation should be to get 
the testers' systems running properly again ASAP so that they can continue 
testing.

There are probably already bugs in rawhide packages going undiscovered because 
the most dedicated testers have broken systems that can't be upgraded!

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page