Jeremy's Thoughts - Looking Back (Forward?) on Fedora Core 5
Cycling, Fedora, MIT SDM and Miscellany

Jeremy Katz
Date: 2006-03-19 18:47
Subject: Looking Back (Forward?) on Fedora Core 5
Security: Public
As Fedora Core 5 is making its way to the mirror sites (and hey, even a leaked torrent or two :-), I now have some time to sit back and reflect a bit on the release. While for most people, FC5 is really only about to begin, for me, it is instead winding down. While there will be updates to some packages that I deal with and there will be the inevitable slew of questions, little bugs to fix, etc, my focus does start to shift some to the future. Before going too far into that mode, though, I figure it's worth calling out some bits and pieces and some of the way they're shaping my thoughts for the future.

In a lot of ways, FC5 has been a very unique release. It's the first Fedora release with a longer than a six month development cycle. Last June and July when I was proposing this and championing it, I really didn't forsee how it would turn out. Although it has given us time for integrating more bits and there are some things that really needed the extra time, overall, I think that the extra time didn't really help. Sure, we wouldn't have had GNOME 2.14 or gcc 4.1 if we had released 3 months ago, but then we would have picked them up in three months instead. The net sum ends up being about the same. And the fact that more was trying to be integrated meant that when we were hitting milestones, things were a bit more trying and tense for those of us trying to tie things up and get them done. So I think that in the future, we'll probably keep sticking with the six-ish month release cycle. I'm sure we'll pull in two weeks here and push out a month there, but the basic mechanics of a six month schedule just feel more sane from the trenches.

One thing that we do need to be a little bit better about for FC6 is freeze enforcement. In a lot of ways, we played things pretty fast and loose with FC5 allowing all manner of things to go in at various late stages of the game. This led to a few cases of me grumbling late at night to fix things and some other unexpected things turning up. For FC6, I'd like to try to do a bit better job of actually having and enforcing some freezes. We've always nominally said that test2 is the "feature" freeze and that after test3, the only changes going in should be relatively obvious bugfixes. While we nominally did this for FC5, there were lots of exceptions. And some of them will necessarily have downsides. So to try to help this for FC6, I think that spelling out the various types of freeze in the schedule and what they mean (similar to what's done with the GNOME schedule) could help us a lot.

Also, speaking of GNOME, with the FC6 schedule, we need to think a bit about what to do about GNOME. We're now basically lined up right with the GNOME schedule. The last minute "integrate the final GNOME tarballs" scramble was not my favorite part of the release cycle. And as some people have noted, it's also ended up meaning that we didn't get all of the GNOME 2.14.0 tarballs. The things that have been missed should be showing up in the -updates repository soon after the release, but it's still not ideal. Overall, though, it was the right decision made for the right reasons. And I'm sure that we'll do the same for FC6, no matter what the decision ends up being.

On the installer front, this is quite possibly the most exciting release in a long while. While a lot of things look similar, a lot of the underlying code for anaconda has changed in ways that I've been wanting to do for years now. We now have much more stable and extensible kickstart handling so that we can start to actually validate and verify a kickstart config in a way other than "try it, see if it tracebacks" :-) We've also started down the road of making the packaging backend a bit more modular and replaced what we use with code based on yum at the same time. While for now, it gives us very little in the way of concrete benefits, it's going to give us a lot of cool options in the future for allowing users to pull in their own site specific packages at install time or installing updates. Also, we finally are starting to support some of the various IDE "hardware" RAID configs out there, which is nice mainly for the ability of the BIOS to nicely boot from them. Unfortunately, the user interface for this can still use some work as it's pretty much an all or nothing thing right now. There's more, but some of it, you'll have to read about in the release notes and/or try for yourself.

Related to the installer, we've also finally gotten around to throwing out the three week hack that was system-config-packages. While the idea was good 3.5 years ago, it hasn't aged well as we've moved into a more repository-aware environment. While the replacement of pirut has the definite downside of no CD support at present, that's something that I hope we can resolve as a later update to FC5. Also, we finally have the simple graphical client to sit on top of yum that's analagous to up2date. This will be a great boon to the less technical users who are more intimidated by the command-line.

One of the most talked about things for FC5 (and FC4 for that matter) is the inclusion of Xen. With FC5, things are much more integrated allowing for a much simpler and integrated guest system installation. Unfortunately, we still haven't fully reached stability in this area and there's still a lot of churn with upstream Xen. I'm hopeful that we'll see more stabilization in the coming months, but only time will tell. Things are definitely in better shape than they were 6-9 months ago.

And then, there are the host of smaller but just as important improvements. Things like the use of SCIM for international input, new system profiling tools, improved (free) media support via GStreamer 0.10, new versions of pretty much everything we ship, the continued growth of Extras, modular X for easier driver updating, a new improved framework for SELinux policy that will let us start to actually package the policy with the package as opposed to having a monolithic blob... The list goes on and on. FC5 is a release to be proud of and everyone that's played a part -- be it by maintaining a package in Core or Extras, helping to document all of the great work that's been done, contributing testing to ensure that things work well for end-users, or even just complaining if you disagree with something -- should be proud of being a part of it.

And next, let's figure out how to make Fedora Core 6 even better. I've got some ideas on specific areas I want to push forward (stay tuned for details in the future :-) but I'm sure everyone else has their ideas as well. And the best way to help make them happen is to start working on them in the appropriate forum.
Post A Comment | 2 Comments | Share | Link



User: mattdm [typekey.com]
Date: 2006-03-20 14:11 (UTC)
Subject: a random note on the future
Thanks for the ramblings. :) As you know, I'm very excited about the future ability to pull from multiple repositories at install time, and to be able to install a new system with the current packages _without_ respinning the install tree. However, if that happens, Fedora maintainers will have to be a lot, lot more careful about releasing updates which don't work under the original installer's environment. For example:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172782
Reply | Thread | Link



Jeremy Katz
User: katzj
Date: 2006-03-20 14:17 (UTC)
Subject: Re: a random note on the future
This is one reason why I'm still fairly apprehensive about enabling this by default as it does significantly change the landscape on what you need to test with an updated package.

At the same time, various people (including yourself :) are already going to the lengths of respinning trees to include updates, so the main difference is one of visibility and possibly having it so that people actually fix the problems instead of pretending they don't exist.
Reply | Parent | Thread | Link



browse
my journal
September 2013