Future releases: Proposal for implementation of separate LTS-to-LTS rolling release channel
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
- Started by
- Completed by
Related branches
Related bugs
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-
* Fork LTS candidate apps off of that channel into another PPA associated with that team (say, ubuntu-
* When the LTS packages are ready to submit as new LTS releases, fork them off into yet another PPA (say, ubuntu-
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://
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/
Work Items
Work items:
Create the "~ubuntu-appdev" (or the like) team: TODO
Create the developer and LTS channel PPAs: TODO
