LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
Recent Features
| |||||||||||||
DistributionsCan Fedora Ship on Time?If a Fedora release has been on schedule throughout the entire development process, it hasn't been in recent memory. Fedora Project Leader Jared Smith's announcement that Fedora 14 would suffer a one week slip came as no surprise, but sparked a long discussion on the fedora-devel list about the project's long history of schedule slippage. Mike McGrath compiled an extensive list of Fedora slips, but it's by no means complete. A quick trip to Google shows that every release since Fedora Core 4 has suffered a slip of at least a week. Reasons for the slippage vary by release, but the blocker for Fedora 14 Alpha was the inability to choose the basic vesa driver when booting and after installation. The specific cause may not be that important, however. John Poelstra points out that every release has different blockers:
Anecdotally, what happened in this release is not
unusual. Each release we have these "this shouldn't ever happen again"
items and while they have different names the reasons are almost always the
same -- landing changes to packages or infrastructure right on the deadline
or not budgeting enough time to recover before the deadline if something
goes wrong.
One example may be large changes that derail other system components. Bruno Wolff III cites Python and systemd as major causes for delays, and suggests that "big changes" land a month earlier for easier testing. Some distributions have different schedules for different components. openSUSE, for example, has different freeze dates for the toolchain, base system, and remainder of the system. In theory this means that the pieces with the greatest impact on the rest of the system are stabilized first and allow for testing of other components without breakage going on "underneath" them. In practice, Adam Williamson says that it's rare for the blocker bugs to reside in the core components in Fedora. But Fedora does have critical path packages that could be frozen earlier in the schedule. This would include components like Anaconda, GNU Bash, GCC, Grub, the kernel, X.org, RPM, Yum, and many others. Smith offered three suggestions starting with documenting the reasons for failure, as Poelstra has already been doing. Poelstra has a detailed list of things that have worked well and those that have not with the Fedora 14 release so far. Some of the problems Poelstra has identified include the Koji outage on July 10 and 11, and a need for redundancy on the Release Engineering team. Smith called for more work to document failures (and presumably successes) to try to address them in future releases. Secondly, Smith called on the Fedora Engineering Steering Committee (FESCo) to "take a more active role in tracking the major changes that land in the distribution and judging the impact that they might have before freezes." Smith noted that Python and systemd weren't the blockers for F14 Alpha, but "had an impact on our ability to build test composes, and also our ability to thoroughly test the RCs" before evaluating the release. Lastly, Smith asked for contributors to help the Quality Assurance (QA) team with automated testing, as too much is being done manually — and Fedora does not have the resources for extensive manual testing. Fedora has been boosting its testing efforts lately with the "proven testers," who are specifically focusing on the critical path packages. Fedora 13 was the first cycle that had the proven testers at the helm, and F13 slipped as well. However, one of the goals for the team is to recruit more people for testing, which may help in the long run. Other posters suggested extending the release cycle, some by just a month, others suggesting a nine to 12 month cycle, but this was not met with a great deal of enthusiasm. Will Woods argued against it, saying that no matter how long the cycle was, it wouldn't "stop people trying to cram fixes/changes in at the last minute." As with Smith and others, Woods suggested "better tools and processes" rather than longer development cycles. How long are the freezes? Users outside the development process may be surprised at how short they are. Peter Jones noted that it depends a great deal on where one starts counting. From development start to feature freeze, the freeze was 43 days for F12, 53 days for F13, and 63 days for F14 — including holidays that fell within the development cycle. From development start to alpha freeze, F13 had 84 days, F12 only 76 days, and F14 just 70 days. In the end, Jones says that "from computing these numbers I think the best lesson is that our schedules have been so completely volatile that it's very difficult to claim they support any reasonable conclusions." Given the frequent changes to the development process for Fedora, there's something to be said for that conclusion. In the end, are the slips really a major problem for Fedora? Williamson points out that the releases are still "reasonably fixed" with less than a two weeks slippage on the last three releases of Fedora. Others have chimed in to say the process isn't broken, and that slipping to fix issues "is a feature not a bug." While that might sound glib, there's some validity to it as well. Fedora long suffered from a bad reputation for pushing out releases with serious, sometimes show-stopping bugs. The latest releases have been, if not perfect, of much higher quality. What of the arguments that Fedora is less dependable for "a project manager looking at using a Linux OS in my project" or that it's losing users due to slips? Fedora's relatively short lifecycle after being released makes it an unlikely candidate for many projects even if it were on time. At any rate, Fedora's release cycle is fairly dependable — it can be expected that the release will slip by a few weeks past the scheduled date, but not much beyond that. The suggestion that Fedora is "losing users" over a few weeks of slippage is also unsupported. Nothing final has been put into place yet, but it does look like the Fedora developers are taking the slips seriously. Over the years, the Fedora community has been aggressive about improving its development processes and addressing perceived issues with the Fedora distribution. If the community remains concerned and focused on avoiding slips, it just might be that Fedora 15 arrives as scheduled. But if it's a choice of quality vs. meeting the schedule, the slips aren't so bad.
New Releases CyanogenMod 6.0 releasedThe long-awaited CyanogenMod 6.0 release is out, bringing a bunch of new features to several different Android platforms. "This is our first stable release based on Android 2.2, and weve hit our target list of devices. Im completely amazed at what this project has become and the community that has developed around it, and its only just getting started."
Distribution News Distribution quote of the week
Why should update policies for the kernel, dbus, firefox, inkscape,
xorg-x11-server, and cowsay be the same? Does that make sense? If an update
breaks my graphics, I can't use anything. If an update breaks cowsay, well...
my clever MOTD is a little less clever but it shouldn't break other
apps. So why not bundle critical stuff that'll really hurt our users in a
huge way — the basics like networking, graphical display, hardware
support, i18n input methods, sound — and put much more stringent
guidelines on them than apps like figlet, xbiff, or xbill? If an
application is relatively self-contained and can really only break itself
— is it so necessary to be as strict about updates to it within a
stable release?
-- Máirín
Duffy
Debian GNU/Linux Debian Project mourns the loss of Frans PopThe Debian Project has put up a brief notice on the passing of longtime contributor Frans Pop. "Frans was involved in Debian as a maintainer of several packages, a supporter of the S/390 port, and one of the most involved members of the Debian Installer team. He was a Debian Listmaster, editor and release manager of the Installation Guide and the release notes, as well as a Dutch translator."
DebConf10 DPL report: comm., CUT, RC, init, derivatives, ...Debian Project Leader Stefano Zacchiroli has a report on his activities during DebConf. Topics include Communication, CUT (Constantly Usable Testing) BoF, RC squashing activities, init system(s), Derivatives, Collaboration with SFLC, and DebConf & Debian.
Bits from ARM portersHector Oron looks at the status of the Debian ARM port. Topics include Official buildds, Hardfloat ARM port, Linaro bits, and Hardware donations.
Fedora Ksplice Removes Need for Rebooting on FedoraKsplice Uptrack is a Linux update service that does not require reboots, and it is now available free of charge for Fedora.
Fedora Board Meeting 27 August 2010Máirín Duffy covers the August 27 public meeting of the Fedora Board. The board addressed questions about decentralized technical direction, funding and organization of Fedora Activity Days, FESCo and enforcement, and Fedora's target user.
Newsletters and articles of interest Distribution newsletters
Duffy: A story about updates and peopleOn her blog, Máirín Duffy describes four archetypes of Fedora users (Caroline Casual-User, Pamela Packager, Connie Community, and Nancy Ninja) and how they relate to updates of the distribution. Fedora has been discussing its update policy for a bit and Duffy uses the user stories to present her thoughts on how to proceed. "Pamela wants updates to be constant throughout a release, no holds barred — she wants the latest Gimp and she wants it yesterday. Caroline just wants her computer to work — "please don't change a thing — it worked yesterday — if it breaks before my presentation I'm screwed!" Can both their needs be met? I think so! But its easy to completely miss where interests and needs can both be met when the language is so easily interpreted to mean the problem is untenable."
Page editor: Rebecca Sobol |
|||||||||||||