Primary Proposal

This is the initial straw man proposal for moving to a rolling release and ensuing discussion is available here: Initial Proposal

The essense of the proposal is:

• Stop making interim releases.
• Keep doing daily quality and keep improving our daily quality.
• Take a monthly snapshot of the development release, which we support only until the next snapshot

Daily Quality is a combination of:

• using -proposed and britney to ensure that users are never exposed to inconsistently built packages
• an ever-growing body of autopackage tests in -proposed to ensure that bugs are caught before they are delivered to users
• whoopsie-daisy to ensure that the crashes that do make it to users are found and fixed in priority order
• phased updates to ensure that grave issues reach as few users as possible and are caught and corrected immediately

Benefits

• Fewer stable releases to support conserves engineering efforts for current development and LTS point releases (also less confusion for users and vendors)
• Less freeze periods = more time developing and testing
• Fresher software and features in the hands of users (as well as resources available for backporting more of these to the LTS point releases)
• Making the leap will force us to "learn by doing" to make our development release consumer grade

Drawbacks

• Could be a questionable replacement for the current release process (doubts about quality of a rolling release at the moment)

• Difficult for some flavor communities to fulfill their mission without a stable base to ship on (alternatives proposed in the Q&A below)

• Supporting the monthly snapshot requires some new engineering efforts (but could be more of an Add-On of the work that is already being done for the daily snapshots)

Sub Proposals

Rolling release + monthly snapshots (Adam Conrad)

https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036798.html

• The primary proposal but without the monthly support, just provide snapshots of the installation media.
• Requires improving -proposed automated testing.

Adding more pockets (multiple proposers)

https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036845.html

• Users subscribe to different pockets depending on how
• Launchpad engineering to accomodate additional pockets would be copious

Launchpad derivatives

Derivatives Distributions is a Launchpad spec to deliver a mechanism for creating arbitrary derivatives of Ubuntu (source or binary subset based on package sets).

• Flavors could used derived distributions to maintain stable archives for the desired lifetime
• Flavors would have to support the derived distro archive
• Would split community efforts across multiple archives
• Current implementation is incomplete and crude, would require a *large* amount of Launchpad engineering to complete

Rolling Release + Upstream stable/beta cadence and limited delta buffer

http://bryanquigley.com/crazy-ideas/rolling-release-w-upstream-stable-cadence-upstream-beta-cadence-and-limited-delta-buffer

• Buffer changes going to rolling release, dont't let them all hit at once
• Provide packages in rolling archive for many beta packages (linux-beta, firefox-beta, etc) to help upstream stabilizaiton
• Try to provide what upstream considers the latest stable (blocked only by buffer)

Q&A

As a result of his proposal, Rick Spencer attracted a lot of questions and offers some answers in Q&A form below; add your own questions and answers (with signature) below.

Isn't the proposal you made a foregone conclusion? Wasn't it really a plan pretending to be a discussion?

• [rickspencer3]

  • No, I really did mean for it to be a discussion and approbriate governance to determine how, if at all, we would take up such a proposal. I have passionate views on the topic, and I tried hard to make the argument for those views. I sincerely hope that the discussion causes us to do the right thing, but where "the right thing" could be something very different than what I specifically proposed.
    I think the straw man proposal was a good one based on a good analysis, but I never thought such a change would be made without proper Ubuntu governance.

So everyone but developers would use the LTS?

• [rickspencer3]

  • That is not how I envisioned it. I think that whoever uses LTS today would continue to use the LTS if they want. Whoever uses Interim releases would use the non-LTS version. Many people who use the non-LTS release do so because they like getting fresh software with new capabilities, but they won't tolerate their system breaking signficantly. So, non-LTS for tech enthusiasts and developers only seems to be setting the bar for our daily quality too low. We should shoot for consumer-grade quality every day. I don't think we'll start out with that, though. But meanwhile, the interim releases are both a crutch (with their freeze periods) and take resources and focus that could be channelled into daily quality on the Ubuntu of the future. At some point we need to make the leap.
    This is a big shift in mindset that we only just started down. The product that we are building is the same product that users are using. But note that other software projects do this. Some are small, some are big. Some are on the web, and some are operating systems. If they can do it, so can we.

Isn't this proposal just a proposal to go to a 2 year cadence?

• [rickspencer3]
  • I think this perspective makes sense if we think that we cannot deliver enough quality between the LTS to make Ubuntu generally useful for people who use the Interim releases today. Otherwise, we will have monthly cadence for planning, and some users will use that cadence for updates. We will have a daily cadence for quality, though.

Isn't changing our release heuristics incredibly risky? Won't we shed users?

• [rickspencer3]
  • Risk aversion is a personal thing. The risk I am worried about is that we don't effectively shift our focus to creating a Converged OS and someone else will get there first. I think we should be marshalling all of our forces to gain that high ground, and shouldn't risk losing it because we aren't prepared to change the way we do things.

What about flavors?

• [rickspencer3]

  • In my original mental model, this wasn't much of a problem. The flavors just use an LTS for their LTS users, and the non-LTS release for those who currently use the Interim release. However, my mental model was wrong, because this does not actually allow some of the flavors to address their mission. If their mission is to deliver a stable upstream every six months on a stable base, they won't have a new stable based every 6 months to build on.
    I think there are ways to ensure that flavors can continue to achieve their mission, but it won't be quite so simple. For example, they could use the LTS and use backports or PPAs heavily, maybe spinning a new release of the LTS whenever their upstream releases. They could snapshot the archive every six months and support it themselves, but I think this would be a very bad outcome. There would be few people supporting that snapshotted archive, and I think there is a lot of benefit to everyone working in the same archive.

• [estelar57]

  • As a user of different flavors like Kubuntu, I try to stay with the LTS by using the KDE PPA and avoid the the 6 month interim releases as much as possible (which imo seem like duplicated effort with little gain). Been doing this for years, so the above proposal of "the LTS and use backports or PPAs heavily, maybe spinning a new release of the LTS whenever their upstream releases." seems valid for most of us users.

What would happen to people currently on 12.10?

• [rickspencer3]
  • I think some of them could simply update now, and then go along with us on the non-LTS release after that. I think for others, we would want to continue to support 12.10 until those users can reasonably expect to update to 14.04.

Doesn't the change to not support 13.04 pull the rug out from under us?

• [rickspencer3]

  • On the one hand, I don't think we should fall into the fallacy of sunk costs. The fact that we had planned to release 13.04 in the normal way does not automatically make it the correct thing to do.
    On the other hand, some of the feedback was from people who were planning products and other economic opportunities from 13.04. For them, it's not a sunk cost fallacy. Of course, any change we ever make to or support policy could have such an impact on people. But maybe the week of feature freeze is a bit close to the deadline to make such a call.

What about OEMs that want to ship "fresh" Ubuntu

• [rickspencer3]
  • Except for a few exceptions, the larger OEMs all ship LTS and are planning to for the foreseeable future. I'm not clear why someone couldn't pre-install 13.04 today. It would go to users, it would update when they first turned it on, and they would be good to go.
• [estelar57]
  • OEMs, users and ISVs prefer the Latest Stable Release (i.e. Windows), but when a new release comes out in the span of just 6 months we make the Last release feel out-of-date, obsolete and antiquated (when that's not the case). The focus should be for OEMs to ship the latest LTS "point release" till the next LTS (which as being an equivalent to "service packs" provide a lot of new functionality and fixes, i.e. like the amount of features that were back-ported for 12.04.2).

Isn't a Rolling Release just spaghetti code? Where is the rigor?

• [rickspencer3]
  • I think "rolling release" does have negative connations for many users. It might imply unpredictability, instability, and other undesirable aspects of software. However, perhaps this is a branding issue, and it is better named the "current" release, or the "edge" release, or similar. The point is that we strive to make the rolling release work every single day.

Is the Ubuntu 13.04 release cancelled?

• [rickspencer3]
  • Converting 13.04 to a rolling release was part of the straw man proposal. In order to accomplish that, I think we would need to have quickly come to a consensus.

Won't syncing from Debian introduce many more problems one Wheezy is out and Debian is unfrozen?

• [rickspencer3]
  • This is only a risk for the software that we sync directly from debian. Our daily quality system should protect us from inconsistencies and bugs.

What about Documentation

• [bkerensa]
  • One concern of mine has been that with faster releases the documentation team would not be able to achieve updating documentation to reflect changes at such a pace. As it is with six month releases were already lacking man power to meet those goals.
• [rickspencer3]
  • Could we add release criteria that required updated docs before packages are copied to the release pocket for users? This would enforce developers working with documentation community in a pro-active manner.

Will Ubuntu 12.04, 12.10 and other prior releases still be supported?

What about the release schedule with respect especially to freezes?

• [bhavi]
  • One of my major questions is about how the release schedule could span out in view of a rolling release esp with respect to freezes. Is the freeze going to be in line with a monthly release or have a freeze say like 4 months or so between LTS releases?