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