Linux, musical road-dogging, and daily life by Paul W. Frields
Into the future.

Into the future.

Because we’re trying to stomp out a handful of nasty bugs — some of which appear to be thoroughly smooshed, and some of which we’re still attacking with the Rolled Up Newspaper of Free Code Wrangling — the Fedora 12 Beta will be pushed back one week.  We expect right now to release it on Tuesday, October 20th. Of course the schedule has already been updated to reflect the latest schedule news.

We’re still working out what this portends for the final release. Generally the QA team’s cumulative wisdom is that changes like this need to echo down the schedule, so that we don’t compress periods of public testing. Many people in the community don’t keep up with daily Rawhide, and depend on a DVD, CD, or Live image release to do their testing. (More on this in a moment.) We want to make sure that the Beta, which is the last release before final Fedora 12, has the chance to be tested by as many people as possible.

This used to be the position and purpose of the so-called “Preview Release” that happened several weeks before GA. However, in an attempt to make our test releases less confusing, we have gone to the industry-standard practice of making Beta the release that is meant to be code-frozen, and ready for wide public testing. The only changes that are supposed to go into Fedora during this period are fixes for problems detected that would make it unsuitable for release.

In which a wrinkle enters the fabric.

To make that testing period as long as originally intended, we’d have to make the final Fedora 12 release a week later as well. There’s a thorny problem in that plan, however. Part of the Fedora infrastructure will soon be undergoing a relocation from one physical facility to another, and that’s scheduled to begin some time around the 18th of November. This is happening toward the end of a longer process that is supposed to be fully complete by no later than November 30th. Currently our final Fedora 12 release is scheduled for November 10, but if we were to echo this Beta slip down the rest of the schedule, that would mean a release on November 17. Moving infrastructure the day after a major release? Our community Infrastructure team is the very definition of awesome, but… Yikes!

So, moving pieces of infrastructure around the day after release doesn’t seem like a great plan. And neither does shortening the period for public testing. We’re looking into whether our infrastructure relocation can be postponed, but of course the week of November 24th has a major US holiday, making rescheduling difficult.

In which you, Dear Reader, play the starring role.

Well, for one thing, by testing the currently available bits for what will be Fedora 12 Beta. The few changes still landing are mainly correcting problems found and noted in filed bugs, but the critical stuff in Rawhide, our development branch, is frozen. When we spin those packages into a release of DVD, CD, and Live media, it takes several days to prepare all of it and get it shipped to mirrors in time for the release date.  And during the days even before that, leading up to the spinning, you can test the vast majority of what will be in the Beta. Here’s how:

  1. Download the boot.iso file found in the images folder for your architecture, whether that’s 32-bit (i686), 64-bit (x86_64), or PowerPC (ppc). It’s under 200 MB in size and contains everything you need to run the installer. Burn the ISO file to a disc and boot your system from the disc.
  2. Proceed through the installation per usual, up until the screen for selecting capabilities and packages.
  3. When the time comes to install packages, the Rawhide repository is selected and will be accessed from the Internet. If you have a local or preferred mirror, you can edit the repository to point directly to it. If you don’t, our MirrorManager will provide you with a reasonable, nearby choice. Make your package selections as usual after the information is loaded from the repository.
  4. Packages will be downloaded from the Internet and installed to your system.

This method may take some additional time, depending on the speed of your connection to the mirror you’re using, but the bits are the same ones that Fedora experts are using every day for installation, updates, and testing of the latest software that will go into Fedora 12.

And most importantly, if you find problems, FILE A BUG! Remember, we’d rather hear about a problem twice than not at all. We have a Bugzilla primer that will tell you what you need to know to file a more clear and useful bug. It’s vital that we get great testing during Beta phases so that we can make the final as good as possible. All software has bugs, but what makes free software improve faster than alternatives is that we can all help stomp them out through an open, collaborative process. You can be a part of that process!


  1. “And during the days even before that, leading up to the spinning, you can test the vast majority of what will be in the Beta. Here’s how:”

    If you’re feeling lazy, you can alternatively just test the nightly live builds:


    of course, that route doesn’t test the conventional-installer bits of anaconda, so we need people to test that route too. But if you mainly want to make sure it boots and gets to a working desktop on your hardware, using a nightly live image is a very easy way.

  2. @Robert: Thanks for filing the bug! I don’t have any Mac hardware so I can’t help you on this one myself. But I did move the bug component, since it doesn’t have anything to do with the “bootchart” component — “efibootmgr” seemed to be the right one, and the people listed as responsible for that component will know the right one if not.

  3. robert: Macs are a rather special case when it comes to booting (due to the use of EFI rather than a traditional BIOS), unless you use that Boot Camp thing (I don’t know much about that). So it’s not unusual to run into issues on Macs, unfortunately. Paul’s change looks to be on the money.

Comments are closed.