jcm's blog

There’s been a lot of talk recently about Fedora’s policy (or lack thereof) for shipping updates to existing stable releases. Rather than keep repeating the same points on the mailing lists ad nauseam, let me give my own $0.02 here. Keep in mind that these are my own personal opinions, and nobody else’s.

First off, I know in using Fedora that I am not using an “Enterprise” distribution that is intended to remain rock solid and stable for a long time without substantive changes. I’m ok with having to upgrade every 6 or 12 months, and I’m willing to deal with fixing breakage when that happens (though obviously in a perfect world the upgrade would be entirely seemless). What I am not ok with is updates shipping that cause any breakage or behavioral changes to my perfectly working system when I have not asked to perform a major upgrade. I expect that, if I upgrade my laptop system ten minutes before a meeting, then it will still work exactly as it did before. I don’t want to have to delay doing any updates – as I do now – for fear of the result.

Since time doesn’t stand still following a release, and bugs and regressions are found – and security issues are raised – a flow of updates to a “stable” release is both necessary and healthy to any distribution. But updates should be just that: updates. And also “necessary”. To me, an “update” is not shipping a major version bump on an existing piece of software, or replacing an entire stack (complete with all manner of behavioral changes – no matter how “small”: it does matter if that menu item moves around mid-release) – after the release. That’s called a new release. Or rawhide. Or whatever. The point is that a release has to have some kind of meaning for it to even be worth having a release. Otherwise, you may as well just call it “Forever Rawhide”.

Now I’m not saying there can’t be flexibility. For example, I don’t personally care at all about KDE update frequency. I’m sure the people who work on it (many of whom I have met over the years) are very nice people, and I know they do good work. But I don’t use KDE (other than a few specific pieces of software, such as k3b), and I haven’t for years. So if KDE is updated ten times a day, I’m not going to even notice. I’d rather, for the sake of the users have a consistent policy, but perhaps that stack could be excluded since its maintainers are quite vocal about being able to make a lot of updates. I would rather an exemption were made for their specific stack rather than have the rest of the distribution need to following the same rolling update trend.

What I am going to notice, however, is if any of the critical path components that I rely upon is broken, has a behavioral change, or is needlessly updated way too often to make any real sense. Needless includes pulling in some minor upstream bits that aren’t materially warrented by actual or likely bug reports. Those things are best done in rawhide where they belong, and where those who are more than willing to test as they go will happily help shake out issues. I myself run rawhide also, but on dedicated real or virtual machines that are only for testing and not intended to be used or relied upon for daily work. Even in the case of rawhide, I think things should be at least reasonably tested on a standalone system (more than just compile tested) before pushing if they stand a chance of breaking something fundamental in the distribution.

Think about it this way. The Fedora development cycle is about 6 months. If you are a user and really, badly need some major new feature, you might have to wait an average of 3 months. Even if that’s hardware enablement that makes the distribution otherwise inaccesible to you, I would rather that you have to wait 3 months for the new version (during which time you are free to try the pre-releases, alphas, betas, etc.) than ship an intrusive update that may negatively affect other users who already have working systems that can already make full use of what they have available. It’s simply not worth inconveniencing existing users of a stable release for the possible benefit of those who are not already using it and can wait until the next time.

Anyway. I think Fedora needs an update policy, and it needs a strong one. If you know me, you know I am far from a conservative guy, but I do think that stable Fedora updates should have a fairly conservative update policy for at least all critical path components. Those should never be updated unless necessary to fix specific bugs, and only in a fashion not likely to cause regressions for other users not affected by those bugs, or who rely upon specific behavior not to change (i.e. not a whole major version bump). The components not in the critical path can have more wiggle room if necessary, but I would still like to see far fewer updates in the stable releases.

Jon.