Future releases: Proposal for implementation of separate LTS-to-LTS rolling release channel

Registered by Kenny Strawn on 2013-02-20

It's amazing how far Ubuntu has come. It's now, thanks to the Ambiance/Radiance themes and especially Unity, not only many times more beautiful than it was before but also much more easy to use.

As we all know, however, platforms like Android and (to a lesser extent) iOS seem to be much farther ahead of Ubuntu when it comes to developer friendliness. Because to submit an application to the Ubuntu Software Center, you need to actually wait for approval just like for iOS... only in Ubuntu's case, it's because of Ubuntu's strict fixed release cycle that does little in the way of allowing submissions to freely flow and does more in the way of making developers (and users alike) wait 6 months for their app to enter the Software Center (and users have to wait that long to be able to install said app).

However, making Ubuntu's repositories rolling release (and therefore more public) between LTS is a sure way to fix that problem (and make Ubuntu potentially more worth developing for than Android), because developers don't have to meet deadlines to submit apps to rolling release distros. And because of that, the apps are less buggy, more polished, and easier to use when finally submitted.

So, in the whiteboard below, I'm describing how this said "beta channel" (so-to-speak) between LTS releases is to be implemented.

Blueprint information

Status:
Not started
Approver:
Mark Shuttleworth
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

* Create a public Launchpad team (say, ~ubuntu-appdev) that isn't moderated and anyone can join
* Create a PPA associated with said team (say, ubuntu-appdev/developer-channel) that would be used as the rolling-release LTS-to-LTS channel
* Fork LTS candidate apps off of that channel into another PPA associated with that team (say, ubuntu-appdev/lts-beta) and fix the bugs in them at least 9-12 months ahead of release to make the LTS releases more polished and stable.
* When the LTS packages are ready to submit as new LTS releases, fork them off into yet another PPA (say, ubuntu-appdev/lts-stable) and they'll update on all LTS systems automatically

The premise of this blueprint is incorrect. The approval process for USC is not at all "because of Ubuntu's strict fixed release cycle". Quite the opposite: it is a huge amount of work to test and reissue ISV apps for new releases, and a rolling release would make this completely impractical. In the worst case, an ABI change could make an application you had paid for suddenly unusable. Now, a fixed six-monthly release is harmful for many reasons, so I'm all in favor of switching to LTSes only plus a *developer-only* rolling release. The biggest risk of this plan is that a large proportion of Ubuntu users would be tempted to run the rolling release instead of the LTS, decimating the addressable market for ISV software. —mpt

@mpt , most of the issues you pointed out for users and ISV's should not be a problem if a Semi or half-rolling model is used instead of a full public rolling, like with Chakra (http://chakra-linux.org/wiki/index.php?title=Half-Rolling_Release_Model). Switching to LTSes/semi-rolling would also be favorable to fixing many of the issues that the fixed six-month cycle generate.

I see no difference between "half-rolling" and what Ubuntu has had since the Backports team was formed in 2005. But backporters are scarce, and I doubt relabelling them would help. —mpt

@mpt, you can correct me if am wrong, but to me half-rolling seems to be the other way around: roll as much software as possible and only freeze things like the core and/or desktop layers, giving the advantage that it can be done by less people/contributors, while in contrast the current ubuntu model is to freeze everything and backport a small amount of features or apps (and still to this date software like gimp 2.8 has not been able to be backported to the LTS as it didn't make it through the freeze date for just a short period). Thus indeed the scarcity of backporters and the short cycles make it a bigger challenge for this type of model. --mob

(?)

Work Items

Work items:
Create the "~ubuntu-appdev" (or the like) team: TODO
Create the developer and LTS channel PPAs: TODO

This blueprint contains Public information 
Everyone can see this information.