Should Ubuntu adopt a monthly cadence/rolling release?
It has been proposed that Ubuntu adopt a rolling release model + LTS instead of a 6-monthly release cadence. This session is to continue the discussion started on @ubuntu-devel:
https:/
Discuss the pros, cons, and consequences of such a change for the Ubuntu community and the project, and perhaps flesh out some of the details of how this would be implemented if we went ahead.
Blueprint information
- Status:
- Not started
- Approver:
- Pete Graner
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Rick Spencer
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Some possile topics:
* Kubuntu has already pointed out that such a change makes their mission more difficult. What about other flavors or parts of the community? (Xubuntu has its concerns presented on whiteboard here: https:/
* Do we really have enough quality in the development release to support such a change?
* Feature freeze for raring is scheduled for this Thursday. Do we go ahead with it while the release schedule changes are still being discussed, or should it be deferred? Either option seems disruptive.
____________
This is an INCOMPLETE, IN-PROGRESS summary of the mailing list thread [mpt]
Table of contents:
- Dropping non-LTS releases
- Introducing a rolling release
- Introducing monthly snapshots
- Dropping non-LTS releases
- Positives
- Matches what OEMs, enterprises, and many end users already do [Rick Spencer]
- and what Mythbuntu already does [Mario Limonciello]
- Less rushing to get features into releases [Rick Spencer, citing Scott James Remnant]
- But would still happen for LTSes, at least as much as now [Matthew Paul Thomas]
- Development releases are now reliable enough for community members and enthusiasts to use them instead [Rick Spencer]
- For example, dist-upgrade no longer removes packages due to unmet dependencies [Colin Watson]
- Code coverage of tests is increasing [Evan Dandrea]
- The error tracker lets us measure quality over time [Evan Dandrea]
- But this reliability might be just because Debian has been in Freeze [Scott Kitterman]
- And because Unity and Compiz have been in bugfix-only mode [Ted Gould]
- But we now have Britney, and Jenkins testing reverse dependencies [Dmitrijs Ledkovs]
- But that reverse dependencies build doesn't mean they work [Scott Howard]
- But our Britney doesn't delay or block migrations [Micah Gersten]
- Maybe it should [Jeremy Bicha, Micah Gersten]
- Maybe a block between raring-updates and raring [Iain Lane]
- But then -proposed would become a logjam [Steve Langasek]
- We already import, and release, Debian packages with RC bugs
- (discussion about prominence of Debian synced stuff)
- Maybe we should check Ubuntu-Critical bugs anyway [Colin Watson]
- That would recreate painful Debian transitions [Scott Kitterman]
- We could block manually, if autopkgtest results integrated with Britney [Martin Pitt]
- Only ~500 people can make a bug RC [Micah Gersten]
- Beta/buggy software is often uploaded into Debian Unstable [Scott Kitterman]
- And even less prevents it from getting into Ubuntu -release
- R has approached 12.10's reliability only since February 27 [Matthew Paul Thomas]
- Would avoid a 13.04 full of "old" code that isn't in phone-and-
- Easier to recommend an Ubuntu version to end users [Rick Spencer]
- http://
- "I would expect the stock download page to *only* point to the last LTS." [Rick Spencer]
- But still confusion, if rolling/monthly releases are widely known [Matthew Paul Thomas]
- Fewer versions in use would make other things easier: [Rick Spencer]
- tech support
- issuing security updates: more time to spend on security features instead [Jamie Strandboge]
- issuing other SRUs [Steve Langasek, Alberto Milone]
- issuing new browser versions [Chris Coulson]
- Would avoid planning a whole release around work items from six-monthly UDS sessions [Martin Pitt]
- Would simplify fixing bugs [Marc Deslauriers]
- Negatives
- Kubuntu would no longer be "a release with the most current KDE" (4.x.2) [Scott Kitterman]
- unless there was a way to build ISOs from PPAs [Scott Kitterman]
- People spent a lot of time planning and working on 13.04 [Jonathan Riddell]
- Implementation
- Use backports more in LTSes, e.g. other-flavour DEs and popular apps [Dmitry Shachnev]
- (Discussion about whether kdelibs is more/less backportable than GTK)
- Other points
- If Canonical decided not to issue security updates, these releases might not be useful anyway [Steve Langasek]
- Would need more compatibility fixes in LTSes, as with UEFI in 12.04.2 [Omar B.]
- No more six-month milestones for doing work, but these weren't that realistic anyway [Ted Gould, Barry Warsaw, Colin Watson]
- Questions
- When's the best time in the cycle to do wide-scale hardware testing? [David Henningson]
- Want to avoid "please test this again in the latest version"
- As soon as possible -- improving triage is up to triagers [Marco Trevisan, Colin Watson]
- What fixes would LTS point releases pick up, if not from a six-monthly release? [Mario Limonciello]
- More important if we can no longer tell people with hardware problems to upgrade to a six-monthly release [Bryce Harrington]
- https:/
- Introducing a rolling release
- Positives
- For people who "love being on the bleeding edge" [Barry Warsaw]
- Negatives
- Third-party apps could break after library transitions [Alishams Hassam]
- "large changes ... might affect things outside of the archive, like Steam" [Jorge Castro]
- Would fragment the user base, unless we say it's for developers only [Matthew Paul Thomas]
- Enthusiasts too [Rick Spencer]
- Implementation
- Integrate automatic package tests with Britney [Martin Pitt]
- Integrate smoketests so that failing images don't end up on cdimage.ubuntu.com [Martin Pitt]
- Or still publish them for Jenkins, but don't symlink them to /current [Colin Watson]
- /latest vs. /current [Loïc Minier, Steve Langasek, Colin Watson]
- But remember that hardware tests are hard to automate [David Henningson]
- But the development version already has that problem [Robbie Williamson]
- Consistent quality would require staging major changes somewhere else
- Examples: KDE betas [Scott Kitterman], Xorg, Qt, GNOME, eglibc [Martin Pitt]
- One approach: More use of PPAs [Scott Kitterman]
- Would mean less testing, because opting in to a PPA is harder
- Would mean library transitions are more difficult
- Problems with using PPAs
- PPAs for non-Canonical contributors have low armhf/powerpc ability [Scott Kitterman, William Grant]
- KDE doesn't compile in qemu (bug 1077116) [Philip Muskovac]
- Fixing these might be an acceptable cost of rolling release [Steve Langasek]
- devirt PPAs would need listing and not throwing away uploads [Stefano Rivera]
- Need a policy for when to move packages from PPA to rolling [Scott Kitterman]
- Another approach: An "-experimental" pocket [Stefano Rivera, Bhavani Shankar]
- This sounds like Debian's "unstable" [Tarmo Alexander Sundström]
- Or a "-proposed" pocket for new additions [Kaj Ailomaa]
- But a new pocket is expensive to create in Launchpad [Colin Watson]
- Maybe that's just a necessary cost of totally changing the release process [Stefano Rivera]
- Might cause conflict between projects with different goals [Colin Watson]
- Make -proposed → -release migration cleverer [Dmitry Shachnev]
- Recursively build all reverse dependencies, and run their autopkgtests
- This is partly implemented already [Colin Watson]
- Would it import from Debian unstable even though it may be mid-transition? [Scott Howard]
- Yes, -proposed + Britney protects us from that [Steve Langasek]
- Other points
- Don't use "apt-get upgrade", use "apt-get dist-upgrade"? [Colin Watson, Barry Warsaw]
- Rolling release would be impractical as an ISV platform [Matthew Paul Thomas]
- API breakage: e.g. messaging menu, application indicators, Unity lenses/scopes
- That's why it should be targeted at contributors only
- Unanswered questions
- Who is the target user? [Dmitry Shachnev]
- "If it's for developers only then I would account that a failure" [Colin Watson]
- When would kernels be uploaded? [David Henningson]
- https:/
- Would packages be auto-synced from Debian testing rather than sid? [Dmitry Shachnev]
- That would make regressions take longer to fix [Colin Watson]
- Introducing monthly snapshots
- Positives
- Would let us "set goals, promote new features" [Marc Deslauriers]
- Would let "technical enthusiasts ... use the development release without having the massive package churn" [Marc Deslauriers]
- and isolating them from bad uploads
- Negatives
- Cost of creating and maintaining them
- BUT security updates for snapshots would be less work than for six-monthly releases [Steve Langasek]
- But lowest-priority security updates might not be issued for monthlies [Loïc Minier]
- Implementation
- https:/
- We could choose the latest known-working daily for each snapshot [Loïc Minier, Martin Pitt]
- Would each monthly be a series (expensive), a pocket, or neither? [Martin Pitt, Loïc Minier]
- New pockets would be a lot of work, e.g. in Launchpad code [Colin Watson]
- Launchpad series would be too expensive to create monthly [Loïc Minier]
- It's only six times the frequency we have now [Robert Collins]
- But still more work, rather than less [Steve Langasek]
- But 24 times the alternative [Loïc Minier]
- Creating new buildd chroots, updating scripts, publishing a full copy of main + universe
- But main + universe might just be entries in a tag database [Philipp Kern]
- More painful upgrades for users, especially with PPAs
- Work for developers: debootstrap, pbuilder, release upgrade tools + data
- Freeze the archive for a couple of days before every monthly snapshot [Dmitry Shachnev]
- Big changes could land just after a snapshot [Nicolas Delvaux]
- Other points
- Questions
- What is the use case for monthly snapshots? [Matthew Paul Thomas]
- "for users who want the fresh software, but don't want to manage the daily grind of updating to ensure that their system is secure" [Rick Spencer]
- "if we create them proactively without much demand we just have replaced a big release every 6 months with six smaller releases every month" [Martin Pitt]
- We could collect stats on how much people use LTS vs. rolling vs. monthly [Robert Collins]
- Would monthly snapshots be subject to the freezes for the next LTS? [Martin Pitt]
- Or freezes of their own, to help in milestoning? [Ted Gould, Barry Warsaw]
- Avoid last-minute changes [C de-Avillez]
- Would they have security updates? [Martin Pitt, Scott Kitterman]
- Push urgent security updates to monthly snapshot users [Marc Deslauriers, Jamie Strandboge]
- Including USNs? [Scott Kitterman]
- Might just mention them in existing USNs [Jamie Strandboge]
- Using just -security, not -updates, wouldn't work because security updates might pull in rolling updates [Loïc Minier]
- Would updating a monthly just update to the rolling versions? [Martin Pitt]
- Would lose the ability to selectively install security updates [Scott Kitterman]
- Would monthly snapshots have SRUs? [Martin Pitt]
- Way too heavy and technically complex [Loïc Minier]
- Would monthly snapshots have backports? [Martin Pitt]
- How would people switch between the monthly and the rolling release? [Loïc Minier]
- Would people be able to upgrade from one monthly to the next?
- Would it be like a mini release-upgrade? [Scott Kitterman]
- "Reconfigure proposed-migration to copy into -updates, then bulk-copy to the release pocket once a month" [Colin Watson]
- But snapshot-
- Then we'd need upgrade testing [Ted Gould]
- Same as for six-monthly releases [Martin Pitt]
- Could "enormously complicate" the update UI
- Would it be better to discuss all this more and change in a later release? [Stefano Rivera]
- "A single hour-long [vUDS] session on cadence isn't going to help much." [Allison Randal]
- "if April were to be the first monthly snapshot, we'd have to freeze soonish any way" [Jeremy Bicha]
