Fedora 12: Crunch time

It's been a crazy week. We're still pushing to make the Fedora 12 final release on time but without compromising on quality. It's been a little hairy over the last two days but we've got what we think is a solid package set in at last, and a first release candidate build has been cut. We still need to do some heavy testing on it and make a final call on whether we're going with the planned release schedule - that will happen on Monday - but at the moment I'm hopeful. We'll make the right decision either way, if we ought to slip the release we will do, and Fedora 12 should be one of the highest quality Fedora releases for a while.

So, what can you do to help? Oh, so much! First, don't let the magic words 'release candidate' mean too much: the RC compose per se really only exists to test the actual image compose process, and the DVD / multi-CD installation process. The bits it contains are just the same ones in the repositories. If you have an F12 installation already - say, from the Beta - and you update it daily, you're getting the exact same bits. You can also get on the F12 train from the nightly builds, and testing that install path is just as valuable as testing the DVD or net install paths.

So whichever method you choose to get on the Fedora 12 train, we need you to test out the package set that will be hitting the repositories tomorrow - there's a small number of updates from today, but they're all very significant ones - and make sure it works. We want to hear about any catastrophic problems, and especially about any cases where the packages from 2009-11-06 work worse than the ones from 2009-11-05. That's key. Post a comment here, file a bug and mark it F12Blocker, tell us on a mailing list or find someone on IRC - any of these will work in such a case.

If you have spare systems, drives, partitions or virtual machines we certainly need installation testing, either from the RC compose or from doing a network install from a Rawhide mirror. We have the installation test matrix up here. There's a couple of ways you can use it. The easiest way is to just do an install the way you usually would have done, then see which cell on the table that installation method maps to. If it's not filled in already, fill it in. If it's filled in but your result doesn't match what's in the table already, edit the page to say so - and include a link to a bug report, or contact details, some way for us to follow up! The other way is to look at the table first, and look for tests that haven't been done yet - white spaces. See if you have the hardware or configuration needed to do the test, and if you do, then do it and fill in the cell. In all cases, if you try an install and hit a serious bug, make sure to file a report to bring it to our attention.

The bottom line is, the more testing the better; just run F12 code anywhere you can and let us know where it's broken. Information is always good.

It's been incredible to see how hard everyone in QA, release engineering, development and documentation teams are working to get this release done and make sure it's great. I'm sure the other teams are all working just as hard, as well. I don't think there's many other distributions where I could start the day watching one of Red Hat's full-time X.org engineers start working on an issue in France in the early morning my time, discuss it with more developers in Europe and the U.S. during the course of the day, and go to bed in the evening (okay, early morning) knowing a couple more paid Red Hat engineers are working on it in Australia. It's a great process to be a part of, insofar as I've been helping by running around like a headless chicken bashing everyone in sight over the head with the blocker list and demanding fixes yesterday!

On another note, congratulations to Ubuntu and Mandriva for their 9.10 and 2010 releases. I hope to get some time to play with MDV 2010 once this craziness subsides :)

Comments

Untitled wrote on 2009-11-12 16:42:
"Post a comment here" Since you made it okay for me to be lazy, here goes. After our "correspondence" in DistoWatch I thought I'd give F12 a chance, but I just can't install it... First tried KDE Live CD. I get as far as the seeing the desktop and then the whole thing freezes and I have to reboot. Tried to download and burn the file a second time but I got the same results. I then downloaded the DVD. Installer goes as far as choosing the location and then freezes. I checked the DVD using the tool you provide with it, it said it was fine, tried again, freezes at the same place. I'm not trying the KDE LiveCD in VirtualBox and it's painfuly slow. It's more like a DeadCD... My Laptop is ThinkPad T500 with Linux "approved" hardware and I'm trying the 64bit versions. It might be too late for you in the process, but if there's any information you'd like let me know.
adamw wrote on 2009-11-12 17:18:
Yeah, it is late, but we can try and figure out what's wrong at least. The odd thing is that Thinkpads are very popular at RH so I guessed we'd have tested this already, and sure enough, there's at least one RH employee filing bugs related to his T500 which he could only file if it were actually _working_. Anyway, let's see. With the DVD, can you try installing with the 'basic graphics' option, and see if that works, to start with? That will install with the 'vesa' driver instead of the native driver, to start with, so then we would have to switch to the native driver to see if we can figure out what's wrong with it, if 'basic' works.
Untitled wrote on 2009-11-12 21:21:
Hi Adam, Well, installation did complete with the basic graphics with the vesa drivers. Here's what I've done since: 1. Changed the driver in xorg.conf to radeon. Restarted X but my screen was garbled. 2. With X stopped I ran X -configure and then copied the generated xorg.conf file to the /etc/X11. Screen was garbled. 3. Changed back to vesa so I can log into X, ran yum update (hoping that maybe this would be fixed with the update), changed back the xorg.conf, restarted X and... still garbled. 4. I then tried to install fglrx but the instructions I found didn't work and then I remember what brought me here in the first place... I don't know if you remember but it was your comment about a certain distribution relying on proprietary drivers, which made me smile. Anyway, in case you want to look into it sometime in the future, here's some information. Some T500 models come with switchable graphics. I use the ATI Mobility Radeon 3650 GPU but perhaps the RH employee uses the Intel GPU and that's why it works for him/her and not for me. I assume things are probably mad at RH before a release and you probably can do without trying to solve my issues. In any case thanks for your time and effort. *** Off to the "other side" ***
Untitled wrote on 2009-11-18 21:04:
Just me again, thought I'd pretend you care and leave an update... Decided to try the KDE liveCD of the final release and the radeon drivers work, so something must have been broken in the specific RC version which I previously downloaded. Thanks again for your time and patience.