Fedora release days aren’t as frantic as they used to be, and why it’s mostly a good thing.
Folks who have been involved in the Fedora project for a long time may remember early releases where things were very frantic on release days. Servers and networks melting under downloads, eager users showing up with many questions and bugs, buzz at the first look at something just seeing the light of day. In my opinion recent release days haven’t been like that, and there’s many reasons for the changes.
The easy and cynical answer people would jump to is that there are just fewer people interested in Fedora releases, with all the competing Operating systems and other things with mindshare. There could be some truth to this, but in my opinion the items below also explain things and in a more compelling way.
Now a bit of a digression for some history: In the Fedora Core days, the “core” images were created and tested inside Red Hat, so release day was exciting in that only a few folks had ever seen it before release day. Then in the Fedora releases started with the core and extras merge. In those early releases, test / alpha / beta / preview composes were made, but really only distributed to very involved testing folks. Until Fedora 13, releases were made from rawhide content.
Fast forward to today and lets look at things that have changed:
On moving to the next release before it’s out:
- Since we branch the next release off, it’s much easier to jump to the next release before it is released.
- There’s much less confusion about being on rawhide or not, and also there’s only one thing you need to do to cleanly switch to the next release (do a yum distro-sync or re-enable updates-testing once it’s disabled right before release).
- Because we branch off from rawhide, more disruptive changes can land there instead of either messing up the branched setup before release or slowing down maintainers.
On number of milestones/test images:
- Back in the Fedora 9-13 days there were usually Alpha, Beta and Preview Releases (a few). These days we make a LOT more of them. This makes it easier to jump in and test. For the Fedora 19 cycle for example we did 29 composes (between Test composes, Release Candidates, etc). This is more work for release engineering and QA folks, but I think it’s really helped bring more testing in from the community and makes it easier to jump in.
On distributing test images:
- General Network Bandwidth has exploded. Where before a test image being downloaded by a bunch of people would saturate the network, it now doesn’t really cause nearly as much trouble.
- The Fedora mirror network has grown over time and theres a LOT of mirrors available in it now.
- There’s more master mirrors. We have 5 master mirrors in one datacenter, 3 in another and 1 more in yet another.
- While test images aren’t mirrored or distributed via torrent, master mirrors can handle the downloads just fine, the datacenters they are in have lots of BW available.
On general stability:
- I’ve been running rawhide full time on my laptop and the number of issues I have hit in the last 6 months has been pretty small. IMHO, our releases have been getting a lot more stable over time. I think there’s a lot of reasons for that: Increased QA, better reporting tools, better updates policy, increased number of people who can fix issues, etc.
- Since the branched is a even more gated/stable rawhide, it’s even more day to day usable, resulting I think in lots of people moving to it in the early milestones where in the past they would wait for release. I used to move to the new release at Beta, then started moving to it at Alpha, now I just stick to rawhide. 😉
On upgrade methods:
- In Fedora 7 and 8 the only upgrade method was via anaconda in the install media, in Fedora 9-17 we added preupgrade to the mix and finally in Fedora 18 we replaced both preupgrade and the anaconda upgrade in media with fedup. Obviously, if you need install media to upgrade you have to wait for it to exist (ie, release day or close to it). Preupgrade had a file in Fedora infrastructure it would check to see if a new release was available to upgrade to, and that was only flipped on release day, so few people would see or use it before release. With fedup you can run it anytime (Although right now it uses images from Fedora 19 Beta to upgrade). This results in lots more people using it before release. You can use it anytime to go to the branched release. If you are going to upgrade there’s little point in waiting for the release.
- Yum has gotten much smarter. Starting in Fedora 13 you could use yum’s distribution-sync command to sync your local machine to whats in the repositories (upgrading or downgrading). This made is a good deal easier to switch from/to branched releases.
On Misc other changes:
- In the early days we did the ‘bit flip’ (change in permissions to make the new release tree readable on the master mirrors) right at release time. The problem there is that then it takes until the next sync of lower tier mirrors before they open up content, this resulted in master mirrors getting clobbered, especially right at release time. So, now we open things up a bit before to allow mirrors time to sync up before the announcement.
The net result of all these things is that many many folks I talk to today (The day before release of Fedora 19) have already been on Fedora 19 for a long while, so the frantic spike of releases is smoothed out over more time. So, we end up with more testers/users pre-release and this means people who do wait for release day get a much more stable and usable release than before. I think this is overall a win. 😉