AlternateImagesByDefault
Launchpad Entry: mobile-arm-alternate-images
Created: November 3rd, 2009
Contributors: Michael Casadevall
Packages affected: debian-cd
Summary
The current focus of the Ubuntu armel porters team is to focus on live images, with alternate and netboot images being a second, lower priority. This spec considers the pros and cons of changing to focus of the mobile team to alternate images.
Release Note
As of the 10.10 cycle, it recommended that the alternate image is used for installations on ARM platforms. Live images will provided on a best-effort system.
Rationale
ARM live images take hours to build due to the necessity of building squashfs file systems on a relatively slow architecture. If a respin of the live image is needed during a milestone or release week, waiting for a respin can take hours for just one variant (since there is a separate squashfs for each subarchitecture as of writing). Alternate images are solely built on antimony, and can be respun in a matter of minutes versus a matter of hours. Furthermore, alternate images allow for greater flexibility when partitioning, and using more advanced installation options.
Assumptions
That any time gained by spinning alternates over live is greater than the time needed to debug and keep these images functional
Design
Implementation
This spec is already implemented from a technical perspective; armel alternate images are created for all current subarchitectures. Any implementation work is making sure these images are functional with the first milestone freeze.
Migration
No migration, only new installs are affected.
Test/Demo Plan
ISO testing will focus on alternate images instead of live images, we can reuse the current i386/amd64 alternate test cases with slight modifications.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.