Distributions

Fedora debates scheduling

The Fedora project has developed a reputation for letting its release schedule slip—on almost every release. To be sure, such slippage is not generally any great cause for alarm, and the decision to push back a release is always made by a public go/no-go vote by the Development, Quality Assurance (QA), and Release Engineering teams, taking the current status of release-critical work into consideration. But, recently, the question was raised as to whether or not this regular schedule slippage has become too regular, and something that the project needs to make a concerted effort to improve on.

Fedora Project Leader (FPL) Matthew Miller opened a Fedora Engineering Steering Committee (FESCo) ticket on the subject on September 25. Miller cited a discussion at the most recent Flock conference about moving to a calendar-driven schedule, which would consist of "not making hard calendar deadlines, but simply setting the release date target based on the same two dates every year rather than working from the previous release."

The more rigid schedule would make it easier to plan Flock and other conferences, as well as to route around holidays, and it would amount to a more predictable release pattern for end users. Notably, though, Miller also said that the weekly go/no-go votes would still take place based on the release criteria. However, if a particular release slipped significantly, the next release schedule would not be pushed back as a result; the project would simply have to deal with a shorter-than-usual development cycle.

Miller proposed the second Tuesdays in May and October as the standard release dates (saying that they arose from the discussion at Flock), and pointed out that such a schedule could mean a shorter cycle for Fedora 22, especially if the current work on Fedora 21 results in slippage. Shortly after opening the issue, Miller noted that the proposed scheduling criteria is already codified as Fedora policy; his proposal, therefore amounts to making a commitment to stick to that schedule, even if it results in shortened development cycles.

Few would argue that predictable release dates are bad, but fixed release dates would impose a different strategy on the way Fedora releases are planned: for each release, the new features accepted for inclusion would be determined by whether or not enough time is available before the upcoming release date—and, unlike today, sometimes there might be considerably less time available than the developers want. This would be in contrast to the way Fedora releases are planned now, where the accepted feature set is the first priority. Extra time to complete accepted features is often what pushes back a release. Under Miller's proposal, that slippage could still occur, but it would come at a price: less time for the subsequent cycle and, therefore, the chance that some desirable feature for that subsequent cycle would not get approved.

Josh Boyer posted a reply saying that the notion of setting the schedule first and letting the new features follow only works under some important assumptions: that decisions about upcoming changes are finalized well before the start of the development cycle, that there are sufficient contributors to work on two releases simultaneously, and that one release slipping will not hurt the chances of a approved change being successfully completed for the following release. None of those assumptions are entirely true, Boyer said, suggesting that perhaps this was the reason that the published time-based release cycles did not play out in practice.

Former FPL Robin Bergeron took issue with some of Boyer's assessment, however. People already do work on more than one release at the same time, she said, because new development takes place in Rawhide. More importantly, though, she contended that the only recent releases to slip significantly have been Fedora 18 and (the current) Fedora 21, both of which incorporated especially deep changes. Fedora 18 included the rewrite of the Anaconda installer, and Fedora 21 involves the "big reboot" of Fedora.next. Miller conceded that his perspective on the slippage issue may have been unduly colored by those releases, but he reiterated that Fedora 19 and 20 also did not ship according to the schedule, and that was what concerned him.

Jaroslav Reznik also expressed his support for being more time-driven, but pointed out several potential pitfalls, based on what happened in previous cycles. First, individual teams can request additional time if they feel it necessary; the Release Engineering team did so in the Fedora 20 cycle, asking for two more weeks. Second, there can be changes holding up a release that would take more time to revert than to complete—for example, the Anaconda rewrite for Fedora 18. And third, the QA process has its inherent uncertainties; some individual bugs can cause major slips on their own.

A more time-driven release process is possible, he said, but:

Similarly, Boyer commented that time-driven releases would demand "being very strict about what seems doable in terms of Changes" for a release. Sticking to a strict schedule, he said, would "require FESCo to be diligent and work with the maintainers to understand how long their Change is going to take, etc. It is also going to require that the maintainers buy into the target dates and process."

That buy in, of course, is the critical ingredient. FESCo could simply announce a strict schedule, but that alone would not persuade individual contributors that they need to alter their workflow, nor would it really provide them with concrete steps to do so. But Miller seems to be working on finding specific changes to the development process that would have an impact. He suggested replacing the current calendar's countdown-style dates (e.g., "Alpha Freeze minus 2 weeks") with specific dates, and proposed that more organized development work be done in Rawhide, so that release branches could be reserved for stabilization work.

Changing the way contributors work in Rawhide is likely to be a lengthy undertaking. But Miller may be taking a good first step by changing the way the schedule is communicated. As he observed in his comment, "this might actually help, because currently when thinking about planning for the next release, even if the basic target is known, the actual dates for various milestones feel uncertain", and, later, "having dates for the full schedule early will make it easier for maintainers to buy in and make more realistic assessments."

Redirecting the course of a project as large an diverse as Fedora is no easy task, to say the least. But changing the way contributors view something as fundamental as the release schedule has to begin somewhere, or else there can be no change at all. And this is, at least, early on in the process of thinking about when Fedora 22 will be released and what it should look like, so perhaps there is sufficient time to steer things in a more time-driven direction.

Comments (2 posted)

Distribution quote of the week

-- Rich Freeman

Comments (none posted)

OpenWrt "Barrier Breaker" 14.07 released

The long-awaited OpenWRT 14.07 release is out. It includes an update to the 3.10 kernel, a new init system (procd), improved IPv6 support, support for system snapshots and rollbacks, support for dynamic firewall rules, a new MDNS daemon, DNSSEC validation support, and more.

Full Story (comments: 47)

GhostBSD 4.0-RELEASE Karine

The GhostBSD Team has announced the availability of GhostBSD 4.0 Karine, based on FreeBSD 10. In this version GCC has been replaced by clang as the default compiler, make(1) has been replaced with bmake(1) (from the NetBSD project), pkg(7) is the default package management utility, Networkmgr is the default network manager, and Mate is the default desktop.

Comments (none posted)

NetBSD 6.1.5 and 6.0.6 released

The NetBSD Project has announced NetBSD 6.1.5, the fifth security/bugfix update of the NetBSD 6.1 release branch, and NetBSD 6.0.6, the sixth security/bugfix update of the NetBSD 6.0 release branch. See the release notes for NetBSD 6.1.5 and NetBSD 6.0.6 for details.

Comments (none posted)

Voting imminent on Fedora's new governance proposal

The Fedora project is contemplating a new governance model built around an elected council. "The Council is composed of a mix of representatives from different areas of the project, named roles appointed by Red Hat, and a variable number of seats connected to medium-term project goals. Decisions are made by a consensus process, in which we work together as a common team to find shared solutions and address concerns, with a focus on giving voice rather than on balance of power." The current Fedora Board is beginning a vote on the proposal; the results can be seen on this page.

Full Story (comments: 4)

Distribution newsletters

• DistroWatch Weekly, Issue 579 (October 6)
• 5 things in Fedora this week (October 3)
• 5 things in Fedora this week (October 7)
• Ubuntu Weekly Newsletter, Issue 386 (October 5)

Comments (none posted)

Schaller: Fedora Workstation Progress Report (Wayland and more)

Christian Schaller has a lengthy update on the progress of Fedora 21. He looks at a number of different features, including Wayland, GNOME 3.14, software installation (dnf and "Software"), and more. "This also highlights one of the advantages of the new Fedora product model where we have one clear desktop product we are targeting, that we can define operating system standards for things like application metadata and apply them to the system as a whole. So for Fedora 22 we expect to make appdata metadata a mandatory part of the application packaging for Fedora, ensuring that any desktop application packaged for Fedora is easily discover able by our users. In the old ‘bucket of parts’ model these things would in practice not happen as there was no clear target that everyone was expected to aim for."

Comments (none posted)

Elementary OS 'Freya' Is Worth the Wait (LinuxInsider)

LinuxInsider reviews the beta version of Elementary OS Freya. "The developers of Elementary OS deserve a good amount of credit. They have developed a very usable desktop design early on and continue to improve its functionality. Part of the reason that the Pantheon desktop works so well is that it does not merely recycle existing Linux system tools to make them fit Freya. Rather, the developers created applications built specifically for Elementary OS. For example, Dexter is an address book. Postler is an email client. Nautilus Elementary is a simple file manager. At first blush, these in-house tools struck me as too simple to be very useful, but the more I used them, the more I liked how they worked. Yes, their design is simple, but their features let me get my work done with little or no discomfort. I barely had the desire to supplement them with more familiar standardized apps from the Debian software ecosystem."

Comments (none posted)