- The number of updates available to any freshly installed system (from officially released media) increases over time and rises up to 2 GiB. We believe there is no reason why anyone shouldn't be able to have these updates on the installation media already, thus decreasing the amount of updates available immediately after installation. This is a matter of convenience, as well as bandwidth and data traffic; bandwidth and/or data traffic in some locations in the world isn't as cheap as you might think, and some of us do not even have internet -those usually get a Re-Spin via the FreeMedia program or get it from a friend.
Another compelling 'update available' issue is this one special piece of software, the kernel. Given the latest kernel being installed on your system right-away, it saves you from having to reboot to run that latest kernel. Some of us (depending on the hardware you want to install on) need installation media built with the latest kernel just so that networking works, acpi and storage fixes or new hardware is recognized properly.
- There will always be a number of bugs in the officially released installation media -as will there be in our Re-Spins, just (hopefully) less. That's just the way it is, bugs happen, it's the price you pay for moving forward as much as Fedora does. And that's a good thing. Without that you probably wouldn't even want Fedora in the first place. In case it prevents some users from installing or upgrading their systems, we feel we can make an effort with our Re-Spins to fix these bugs for these users.
- While we make the effort of Re-Spinning Fedora, and distributing it properly (GPL compliance and all that), we hopefully prevent that hundreds or thousands of others also Re-Spin, each of them re-inventing the wheel when issues with Re-Spinning come up, back-porting fixes or tracking bugs being solved in packages, etc.
So, what does it take? What does it take to Re-Spin, and once you've done that, to release the spin to the general public?
First of all you gotta have hardware. We now have i386, x86_64 and PPC available, although we only release i386 and x86_64 this time. Second, you need some bandwidth to distribute whatever product comes out of the process -without bandwidth, distributing the product amongst people testing will become a large bottleneck at some point. Third, you need a couple of volunteers backing you up. Fedora Unity just so happens to have a couple of volunteers, I'm just one of those. These volunteers do what they can to help getting things done, and that isn't limited to Re-Spinning Fedora (at all), given the Fedora Unity mission statement. Some of us help distributing by donating disk space and bandwidth, others keep our servers running or help testing, tracking and resolving bugs, and help documenting stuff to help you getting other stuff done.
For this latest Re-Spin -which we are about to release unless a serious bug pops up in our testing process-, I'll tell you how it went down.
We started harvesting bugs related to installation procedures about 3 weeks ago, verifying that fixes applied would help solving the issue during install time. About two weeks ago, I started composing Re-Spins with fixes in anaconda being back-ported from development into F8 stock anaconda, and listed the bugs I was interested in solving with this particular Re-Spin attempt. I think I did a number of blog-posts calling for people that experienced those bugs and asked them to start helping in testing on whether these bugs had been resolved -some of you actually responded and confirmed bugs being fixed (Thanks to all of you!). I started with Re-Spin '20071204', which didn't solve anything, then composed '20071207', which had one bug solved, I did '20071209' -which didn't satisfy me either, only to come up with two sub-sequential Re-Spins versions '20071211', the latest of which is the version in our testing process now.
Mind that each of these Re-Spins takes about 4 hours maximum to compose, and each of them have some preparation time in investigating why a previous Re-Spin did not fix what it was supposed to fix, attempt fixing it and getting it into a Re-Spin. Basically, composing each Re-Spin takes about a day of investigating, composing (fairly unattended, just check progress every once in a while), preparing for distribution and actually distributing it. Then it takes another day for our testers to test if a certain issue had actually been fixed.
Now that our final version is in the testing process, namely '20071211', a couple of tests need to be run against it. This is our Fedora Unity Re-Spin Q&A sorta speak. We're talking about 22 tests for each architecture, so 44 tests in total as we do i386 and x86_64, each having to be verified by preferably two of our testers. You can imagine the burden on our testers, and the more testers we have for this stage of releasing a Re-Spin, the less time it takes to get all these tests done.
For a matrix keeping track of tests being performed and ACK'd by our testers, check the matrix by our Test team lead, Ben Williams. You can only imagine the amount of work these guys get done.
As I said, since December 11th 2007, our Re-Spin is in testing and we could use some more volunteers to join us, if only you are not running a particular test but join the test team and just use the Re-Spin for your daily system installations and give us the feedback.
Concerning this re-spin, a big thank you to:
- Robert 'Bob' Jensen (BobJensen or EvilBob -testing the PPC images)
- Ben Williams (Southern_Gentleman -testing, testing and testing some more)
- Jonathan Steffan (daMaestro -keeping our websites and servers going, developing software that gets this stuff done)
- Dana Hoffman Jr (Harley-D -testing, testing and testing some more)
- Yves Desgagne (confirming the 'cdrom' installation source issue)
- Keith G. Robertson-Turner (confirming the i586 bug #367731)
- Stewart Adam (developing software that gets this stuff done)
- ... and all others pointing me to bugs they need to be resolved with our next Re-Spin