Fedora 13 Alpha!

Our first major test release for this cycle, Fedora 13 Alpha, is now available! You can read all about it in the release announcement on the wiki.

I’m running it here and would encourage contributors and early adopters to try it out. We could really use your help in finding remaining bugs so we can squash them before the Beta release near the end of this month. You can find a list of common bugs on the wiki as well.

Karma made easy.

Till Maas constructed a truly useful Fedora Easy Karma script in Python. There’s a wiki page about it already, and it’s very easy to use. I just used it to test and give karma to a handful of packages in the pre-release Fedora 13 updates-testing repository in just a few minutes. It’s a great enabler for our community. You do need to have the latest fedora-packager package installed (currently in updates-testing) to use it.

Nice work, Till!

Finding the next failure.

I caught up on the last couple days of the Planet, and found two particularly interesting posts, one by Kevin Fenzi and the other by John Poelstra. The former contains a years-old (but still 100% accurate) presentation on protecting an open source project from threats from within. The latter contains a rallying call against stagnation, and reminds us of the silent 5th ‘F’ in our project values — fail faster.

To improve Fedora, as a project we need to be willing to embrace some level of change. We can do this with the confidence that we don’t need to write change in stone just to make it happen. Looking back through the history of Fedora, we’ve been through some level of change continuously since the beginning of the Project. Sometimes the changes we’ve made have been to discontinue processes that don’t work. Excess governance comes to mind, for example, or having all our media and swag rely on someone in Red Hat. In other cases we’ve struck out to find new ways to collaborate, like expanding our roster of premier Fedora events, or setting up unique communications channels like Fedora Talk.

Whenever we’ve made these changes, we’ve tried to ensure we were identifying and solving specific issues by doing so — in other words, changing not for the sake of change, but to improve the Fedora Project and our software. The particular issue we’re faced with currently is how to resolve many different ideas about what Fedora users should expect from our stable releases. Recent discussions show that there are several competing ideas in play, and when disagreements exist, fortunately we have leadership bodies to help resolve them. This isn’t the first or last time that the Fedora community has found that we hold a variety of views yet need to find a unifying direction.

I brought up Kevin’s and John’s blog posts earlier because even though the content was created years apart — a Google video from 2006, and contemporary thoughts on embracing change — they both are completely applicable to Fedora as part of our shared philosophy. A prominent point made early on in the video Kevin posted is that attention and focus are valuable and scarce resources in any open source project. The presenters are largely pointing back to works like Karl Fogel’s excellent book Producing Open Source Software, which Red Hat’s Community Architecture and I continue to regularly recommend to people we advise.

To succeed, the presenters assert, a project must achieve a shared understanding of its mission and scope. Our mission includes producing a distribution that serves as both an effective R&D lab, and as a vehicle for attracting interest in and contribution to free software. Being unafraid of changing our approach improves our ability to reach these goals. Moreover, doing so is just as much a part of our founding precepts of community as openness and transparency. As John points out, this isn’t a problem with a binary solution for all time. (Many problems worth solving have that in common.) We have opportunities to improve continually, and as a project we need to be more aggressive about taking them. The prospect of failure is much less frightening than the prospect of stagnation.

The Fedora Project Board and I have been interested in leading this change for some time. In October set out a broad definition of a user base that would help guide decisions and choices about how to continue to improve the Fedora distribution — the sum total of software that we promote as part of the Fedora Project. The set of issues around how, when, and to what extent we provide updates is just one aspect of these improvements.

We went through many open discussions to get to that point so we could build a reference and a basis for helping to guide appropriate change in the Fedora Project. The Board and I want to make it easier for FESCo to make coherent decisions around distribution policies such as updates. Sharing an understanding of the wide user base we’re trying to serve helps us better identify situations that are problems for that broad group. Then we’ll find ways to solve them, iterating through successes and failures and learning from them if necessary — as we’ve done in Fedora from day one.

Reminder: Docs bug sprint tomorrow 2010-03-06.

In case you didn’t remember from Eric Christensen’s earlier post, there will be a Docs sprint tomorrow: 2010-03-06 UTC 1500-2100.  We have a flexible but solid agenda for work, and there will be plenty of opportunities for new contributors to participate. We’ll help people get used to Bugzilla, show you how to locate and work on documentation, and most of all, have fun doing it.

Come meet us at IRC Freenode (irc.freenode.net) at channel #fedora-docs for all the good times. See you tomorrow at the bug stomping!

I’ll be there closer to 1630 UTC, because of my daughter’s skate lessons — looking forward to seeing everyone there.

Catching breath, no. 75.5.

Upgrade went smoothly, although I did run into this common bug at the very end of the process. Not only was the bug known about, it’s already been fixed, so no one should see it in the next test release. Nice work Anaconda guys!

The bug’s been written up on our “Common F13 bugs” page as well. That page is where we record issues that we’ve seen in the test release, to lower the surprise factor even for people who are gearing up to test our pre-release software. As we go through the release cycle and these bugs are stomped out, we edit this page as needed. Because it’s a wiki we invite our community to help us document problems there and track them throughout the release cycle — a great way to collaborate that can help innumerable other people helping to test Fedora.

Other than that issue — which itself required no mitigation on my part anyway — the update was extremely boring (just the way it should be). I’ve already noticed a few things worth calling out:

• The NVidia 8400M GS video card in my laptop supports 3D and compositing out of the box with the new nouveau driver and the mesa-dri-drivers-experimental package. The compiz compositing manager seems to work fine, and although GNOME Shell is still in the process of being ported to the new Clutter toolkit version, I expect that will be giving me joy shortly too. I’m thrilled to see NVidia joining the advances made in the free ATI radeon driver in our last release just a few months ago. That’s walking the walk when it comes to free software!
• Mozilla Firefox 3.6.1 showed me a standard notification that I had some add-on updates available — integrated perfectly with my desktop. Unexpected and very cool!
• The new cursor theme has thicker action forms (or whatever it is you call the shapes into which it changes as you move it over actionable things), and makes it much easier to discern shapes and expected actions.

That’s just what I saw in the first few minutes. I’m really looking forward to seeing all the other excellent new features coming in Fedora 13. Our first pre-release, Fedora 13 Alpha, is due next Tuesday, March 9. If you’re a savvy Linux user who wants to see the latest and greatest new technologies, you can pick up a copy and help advance the future of free software by testing the pre-release and reporting bugs. The more we squash in the pre-release, the better the final Fedora 13 will be. With 0ur recent move to a special pre-release branch,

I’m expecting a very solid release — but nevertheless I am very much looking forward to exploring the nooks and crannies of Fedora 13 Alpha, especially if what I’m using now is any hint of what’s to come!

Catching breath, no. 75.

This morning, I’m doing an upgrade of my main workhorse laptop from Fedora 12 to what will soon be Fedora 13 Alpha. I may not be using the method that most people use for such an upgrade. Here’s how I’m doing it:

• I have a mirror of fedora/linux/development/13/x86_64/os on a workstation, which is connected via Ethernet cable to the same router as my laptop, and is offering that directory tree over HTTP.
• From that area, I copied isolinux/vmlinuz and isolinux/initrd.img to my laptop’s /boot folder, appending -f13a to each filename, and made an entry in /boot/grub/grub.conf:

  title Install F13 Alpha
      root (hd0,0)
      kernel /vmlinuz-f13a
      initrd /initrd.img-f13a

• I rebooted, held down the Ctrl key so I’d see the boot menu, and booted into this entry.
• Once the installation process started, I chose the URL installation method and pointed the installer at my HTTP server, specifically to the …x86_64/os/ folder under which the images/install.img file lives.

That was it. So far the upgrade process is actually a bit boring really… which is a great thing to say about an upgrade process.

The work that the Anaconda team has put into this release really shows. Choices are more fully explained in understandable terms. Icons make more sense and better illustrate the process you’re choosing. I’m going to do a fresh installation to a VM later so I can see how some of the other code paths work, but I’m totally impressed with the improvements.

I know that once I start up the new Fedora 13 pre-release, I’ll have more goodness to report.