Rawhide stability

[Andrew Haley]

Andrew Overholt writes:

 > For a while I've been thinking about rawhide stability.  I know we
 > all love to say how it eats babies and it's really easy to tell
 > someone "I told you so" when they try rawhide and complain that
 > it's broken.  But I'd like to start a discussion about whether or
 > not it's possible --or even worth it -- to maintain a relatively
 > stable rawhide (and yes, I realize the term and/or the situation
 > may be changing with the merge).

I think this is probably a mistake.  Let's imagine that we improve the
stability of Rawhide.  The only way to do that is to raise the bar so
that unstable packages are excluded.  So, with Rawhide now stable
there will be no place to put unstable packages for testing.  What
will happen then?  People need to get unstable packages tested, so
they have somehow to be distributed.  Either people will put RPMs up
on web sites, or someone will have to invent Rawerhide.  And then we'd
be back in the same position, but with Rawerhide substituted for
Rawhide.

 > Can we achieve stability while still pushing the latest technology?

By definition, no.  If you wait for it to be stable it's no longer the
latest technology.  It's not called the "bleeding edge" for nothing.

Note that I'm not saying that our processes can't be improved!  And I
certainly am not advocating a cavalier attitude to testing packages.
But I am saying that we have to accept that developers and packagers
aren't perfect, and mistakes will be made as part of our drive to
improve the software that we ship.  Rawhide is an important part of
the way that we ensure that those mistakes aren't still present when
we make a release.

Andrew.