Linux, musical road-dogging, and daily life by Paul W. Frields
 
F12 minus two days.

F12 minus two days.

I’m incredibly excited about the upcoming release. I’ve been running the pre-release of Fedora 12 for some time now and it’s really solid on all the hardware I have at home, including a netbook, a couple workstations, and my workhorse laptop. Such a great job by everyone involved, I’m truly impressed. As we near the release, I’ve been thinking about the idea of update discipline. This is just the term I happen to give to the idea of making sure that updates are solid and making life better for all users of Fedora, including our growing contributor base, consistently. One of the things it brought to mind was the way our community self-regulates.

The connection I made mentally was that there are undoubtedly packages in the Fedora repository — probably several thousand of them — that are in the proverbial long tail of use. In other words, many packages probably have a limited audience and are fairly unique. These aren’t things like core libraries or even special frameworks, but things like one-off utilities or other “edge” packages. Heck, I probably maintain one or two of those kind myself, partly because they’re low-risk or don’t often change. We’ve got over 15,000 binary packages in Fedora 12, and it’s a vast assortment from the most basic functionality almost every piece of code needs, to highly specialized tools or libraries. We have the ability to self-regulate not only this package set, through continually including new and exciting software, but also the way we approach updates to that software.

When edge packages have an upstream change, it’s often minor, or affects very few people. There are lots of perfectly good reasons for those packages to update in a stable release like Fedora 12. (Of course, we want any such changes to avoid any repository breakage, and it’s still important that Fedora provide the automatic tooling necessary to resist any such breakage.) But there are quite a lot of packages that are important across the board. Recognizing this, our release engineering team has been working for some time on the definition and application of critical path. That is, packages so important to Fedora that a special level of care should be taken to ensure they function as well as possible throughout a stable release.

Somewhere between this critical path group, and the entire universe of Fedora repository packages, is a line we might be able to use as a community for some self-discipline when it comes to updates. Maybe that line is at or close to the critical path; maybe it’s a little further out toward the edge than that. One way to think of that line is that it separates “stuff that lots of people are likely to use” from “stuff that relatively few people are likely to use.” But wherever we draw that line, as a community, we could find a comfortable spot on one side of which we’d be careful about pushing updates that aren’t fixing specific problems such as bugs or security issues for Fedora 12.

In my mind, this could go hand-in-hand with the re-working of Rawhide as a non-installable tree. If Rawhide is simply another repository from which you can update packages, it’s easier to think of it as a place for regular upstream rebases, offered to users who always want the latest and greatest regardless of regressions or changes. Now certainly there are cases where upstreams issue new releases that fix a single, specific bug or security issue. In those cases, releasing the new upstream to a stable Fedora can make perfect sense. But that’s often not the case, so I’m hoping that each of us packagers (including myself, since I maintain a few too) can look carefully at our updates over the next few months, and renew our dedication to quality in the updates we provide.

We’re starting with an exceptional release in Fedora 12; let’s see how we can do the best job possible of keeping it delightful for each other, and all our millions of users worldwide. I’m looking forward to working with FESCo and our packagers more over the coming weeks on ways we can enhance Fedora’s stability while still continuing to keep the best of free software in front of our users and contributors. Our community has done a tremendous amount of self-improvement over the years, so I have high expectations for the future, and hope you will too.

Two days until Fedora 12!

3 Comments

  1. If Rawhide is simply another repository from which you can update packages

    Except it’s not. It’s all or nothing. Due to soname bumps in some systemwide libraries (the usual suspects, starting from OpenSSL, but there are several other repeat offenders) used in dozens of packages, it is usually NOT possible to update just individual packages to Rawhide. The new package will require new system libraries which in turn will drag in rebuilt (and possibly also updated) versions of ALL the packages requiring those libraries. By going back and forth through the dependency graph this way, you easily end up with dozens of packages, up to almost the entire distribution, upgraded to Rawhide. So at that point, you’re running an unsupportable and untested hybrid of Rawhide and the stable release and you’re forced to just upgrade the remaining packages to Rawhide as well to clean up the mess. But the thing is, people DO NOT WANT to run Rawhide just to get the new version of the application they need, they want to get new versions where they’re safe and keep the disruptive changes to the next release.

  2. That said, of course “the latest and greatest regardless of regressions or changes” is not something we want to push as updates to a release. But banning all “updates that aren’t fixing specific problems such as bugs or security issues for Fedora 12” except for “edge packages” which “have a limited audience and are fairly unique” is going too far, unless your definition of “fixing specific problems” also includes fixing bugs which aren’t necessarily filed in our Bugzilla and adding new features which don’t break anything and which happen to be contained in those same new releases required to fix bugs (this includes e.g. the KDE 4.n->4.n+1 updates: there are no 4.n.x releases after 4.n+1.0, so upgrading to 4.n+1 is the only way to continue providing bugfixes; but it’s not limited to that: many smaller upstream projects don’t have bugfix-only stable branches at all, but only mixed bugfix/feature releases).

  3. Pingback: Paul W. Frields: F12 minus two days. | TuxWire : The Linux Blog

Comments are closed.