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. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
