Providing monthly snapshotting of the rolling release

Registered by Steve Langasek

To complement a rolling release which offers developers a constantly-usable distribution while staying on the cutting edge of Ubuntu development on a daily basis, we propose to offer snapshot images on a monthly basis that enable users to stay close to the action, while applying updates on a more modest schedule. Security support will be provided for the snapshots, but each snapshot will only be supported until the next becomes available. Discuss the implementation details.

Blueprint information

Not started
Steve Langasek
Colin Watson
Needs approval
Adam Conrad
Series goal:
Milestone target:

Related branches



== Tentative work item list ==
Add apt-setup/updates preseed
Add cdimage control to set apt-setup/updates
Analyse LP overrides bug
Fix overrides bug, or work around it by adding one-shot copy-and-delete facility
Check that proposed-migration will work when the target is a partial suite
Write script to do monthly updates-to-release landing
Draft monthly release process
[desktop team] Need a simple mechanism in software-properties for switching from monthly to rolling and back; nice to have: cmdline way wrapper (esp. if there is an orthogonal structure in place already for other similar purposes)

== Monthly release timeline ==

* Near the end of the month, switch dailies to not include updates (non-rolling)
* Copy raring-updates to raring, along with all publishing history (e.g. override changes), to allow QA-ing the image with updates disabled
* Process pending removals (as we can’t remove packages from -updates which are still in raring)
* Iterate on QA; if the latest image is broken, take the preceding one that has updates disabled
* After release turn on updates again in the dailies

== How do we build -security? ==

Instead of uploading security updates directly to the development series, the security team will change to uploading them via their PPA and copying to -security, the same way as they do for stable releases at present.

The PPA already builds only against the release pocket (i.e. raring, not raring-updates) and itself, so this will work naturally with the proposed new model.

No engineering changes are necessary to make this work, although the security team will probably need to update their internal documentation.

Do we want USNs emails for the monthlies?
[jdstrand] current thinking is yes for the important updates we push to -security but no for those we fix only in -proposed (but this may change pending further discussion)

== Known issues ==

* Need to manually turn on/off updates in dailies
* Some dailies have -updates, others don’t; could be reflected in HTML description on cdimage and on boot screen / boot logo
* In rare cases installation might break if the archive is incompatible with the installer (libreoffice help files, kernels, langpacks...); mitigated by deferring removals and could also make developers aware of this to avoid breaking the installer from the last monthly release
* Can only completely remove packages after a monthly release (avoids library removals)
* How do we handle hardware-enablement stacks/backports?
  There's another session on that

== Other solutions considered ==

* APT pinning (complex, wouldn’t really solve the problems it was proposed for)
* Creating series (lots and lots of churn, probably far more effort than it would justify)
* Instead of staging intra-monthly changes in -updates, have update-manager only offer changes once a month (rejected by sabdfl because applying security updates mid-month would pull in other changes too)

#micahg 2013-02-28
Perhaps a second britney migration could be used to push packages to the "monthly" snapshot. It could check for RC bugs and possibly rerun the autopkgtests and installabillity checks. This would make the monthly snapshot more akin to Debian testing and the rolling release unstable. This second migration check could be run in report-only mode daily so that people can make sure that when the time for migration comes, it just needs to be enabled.
This would keep the buggier packages out of the monthly snapshot. We could also decide, like Debian testing, if a package is too buggy, remove it from the snapshot until it's fixed.

[vorlon] Such an approach would imply that we are giving higher priority to quality in the monthly snapshots than into the daily release. That is not the goal; the rolling release should already be of high quality, and any bug checks / autopkgtests should be run on packages /before/ they hit the rolling release. (And for installability checks, this already happens). We shouldn't be doing things with monthly snapshots that imply that they are higher quality than the rolling release; they're only meant to be more /stable/, not higher quality. In the same vein, we don't want to be doing hands-on management of the contents of the snapshot by removing packages /from the snapshot/ - if the package is that buggy it should be removed from the rolling release altogether.


Work Items