Your Linux Data Center Experts

Since the release of Fedora 9, I have seen a number of folks pop up on the #fedora support channel on irc.freenode.net with the following statement: “Fedora 9 was released with all kinds of Beta software, it's not usable, why would they call it a stable release with a Beta X server, Beta firefox, and Beta package management system?”

I think this misunderstanding comes from folks not understanding how distributions are put together. In the end I think Fedora 9 is quite a good release, even given the Beta packages in some areas.

Read on for my take on how a distribution is put together and why Beta versions are OK sometimes.

First of all, let me say that my experience is with how Fedora is put together, and this may all vary in other distributions, especially LTS or conservative distros like RHEL, etc. Fedora however is a fast paced bleeding edge distro. In addition, Fedora uses a time based release, and releases a version (roughly) every 6 months. This is pretty breakneck speed for software development, but it's a great wave to ride: New features, fixes for bugs, new packages and all.

Lets take a look at a typical Fedora release cycle.

When the new cycle starts, a stable release has just been pushed out to the world. Package maintainers move from focusing on testing and polish on the last release to looking ahead at the new release. At this point maintainers look to see if new major versions from their upstreams are going to be finished (ideal), possibly be finished, or have no chance of making it into the next release, 6 months away. Note that many package maintainers in Fedora are heavily involved with their upstream projects, in some cases they are release managers or project heads for their project, so they have a lot of influence and information about how the project is going. Note however, that until the Fedora time machine is perfected, no one knows what will be available in 6 months, it's all guesswork.

After looking at the information they have, the Fedora maintainer could then decide to package up the beta or prerelease version of the package for Fedora rawhide users to test. This is usually done when there is a good chance the final version will land before the end of the Fedora release cycle, or the package is in a good enough state where it can be fixed up based on rawhide testers.

Once a package is in rawhide, it gets tested out by the many folks who use rawhide and test it each day. I don't have any numbers, but there are a LOT of rawhide testers out there. The more base and heavily used a package is, the more testing it will get. Something like the X server for example or firefox will get tons of testing by rawhide users. In this phase of the cycle, bugs are filed, fixes are tested, patches are upstreamed, new releases are updated, and so on. Toward the end of the development cycle even more folks use rawhide when it's become frozen before release, this results in even more testing.

As the cycle moves on, Alpha and Beta and PR releases are made. Especially with live media this is an easy way for folks that aren't using rawhide every day to test out a 'snapshot in time' of the next distribution. Many bugs are filed and fixed based on this testing.

At the point just before the Beta release, comes “Feature freeze”. This is the point about mid-way through the cycle (release still 2 months or so away) where package maintainers need to look at there packages and decide if they are going to be ready for release in 2 months. If a package has or is going to have a final release weighs into this, but much more so is: Feedback from rawhide testers, feedback from alpha release testers, upstreams commitment to solving any issues that come up, general advantages to the release and new features, disadvantages to waiting for another cycle (perhaps it would cause problems for related packages), cost of reverting back to and older version which hasn't gotten any new testing in this cycle and other factors. Note here that “It's beta” is only a very small part of this decision, and with the time machine not yet running, no way to tell what will happen in the next 2 months of the cycle. Sometimes the maintainer will decide that the package is not going to be ready for release, and go through the pain of reverting it back to a previous version.

After this decision point has been made, the release continues with bug fixes and close integration with upstream to try and get the packages either released before Fedora release, or at least get them into a good and manageable state. It is still possible to revert at this point to an older version of a package, but as time goes on it's less and less desirable. The longer it's been since a older package version was tested and integrated, the less desirable it is to revert back to it.

Then, just about 1 month from final release of the new distribution comes Final development freeze. This is the point at which versions are pretty much locked in for release. Patches to fix specific bugs can go in, and in some cases upstream updates, but each must be carefully inspected to prevent regressions. If there is a prerelease or beta version of a package in rawhide at this point work goes toward getting it stable and tested.

Finally the big day comes, 6 months after the cycle started, the next release is made available.

To move to more specifics of the last Fedora development cycle, lets take the cases of the 3 packages I see mentioned most in the argument from a number of #fedora folks:

X server: The X server shipped with Fedora 9 is version: 1.4.99.901-29.20080415. The Fedora X maintainer also happens to be the release manager for this version of the xorg packages. At the beginning of the cycle (more than 6 months ago, remember?) it was hoped that the 1.5 X server would be released right before Fedora 9, so he updated the packages in rawhide and worked very hard on fixing bugs and solving any issues that came from the testing there. Overall this version works great in F9 release. There are some outstanding bugs with some particular intel cards, but it's working great on all the machines I have here. Note: binary drivers from other vendors don't work against it yet, but that's not the X servers fault. The ABI has been frozen for months, and there are not too many blockers before 1.5 final is released. I expect F9 will see a update to the final 1.5 before too long.

Firefox: Firefox shipped with Fedora 9 is version: 3.0-0.60.beta5.fc9. Again, the firefox maintainer in Fedora is heavily involved with upstream development. This version is a great improvement over firefox 2 that was in Fedora 8. The rc's are out now, and I would expect a final firefox 3 to be made available as a Fedora update as soon as upstream releases it. This version is faster, has more features, and fixes a ton of memory leaks.

PackageKit: PackageKit (the new software manager) as shipped in Fedora 9 is version: 0.1.12-12.20080520. This one is a bit of an interesting case. It was decided early in the development cycle to include PackageKit, but not yet make it default. However, later in the cycle it was determined that the old GUI package manager, pirut, was not going to be maintained much longer. This resulted in the decision that a less complete, but much more heavily maintained upstream package manager was the way to go. It really would have been better to get PackageKit in the next cycle, but there wasn't much choice with pirut support going away. The Fedora maintainers for PackageKit are also the upstream developers, resulting is very good response and communication. I would expect a PackageKit 0.2 to get released as an update as soon as it's final upstream.

So, to summarize, the development cycle is a 6 month process, where it's hard to say what will be ready at the end. You can't simply drop a new package in at the end and ship it, it has to go through the entire cycle. You also can't simply drop back to an old version of a package, which might no longer be stable with all the other updated packages. Given this, we have to trust our package maintainers to know what the right thing to do is. A version number is a small part of how usable or not usable a package is. There have been many packages in the history of software with X.0 that should have been Betas. There are many packages that have been sitting in Beta for years, even though they are quite usable.

Specifically to those that disagree that any of the above packages should have been shipped with Fedora 9: Get involved! Test the F10 alpha and beta releases and file bugs. Offer to help bug zappers triage bugs and give feedback to maintainers about stability. Use rawhide day to day on a test system and file bugs.

comments powered by Disqus

Join our other satisfied clients. Contact us today.