ChannelSchemaSpec

Revision 6 as of 2015-03-06 01:14:43

Clear message

Summary

The image-based updates server makes it possible to produce a large number of distinct channels for different purposes. However, experience shows that once created, this proliferation of channels becomes very difficult to manage. This document is a proposed method for managing the combinatoric explosion of possible channels.

Multiple axes

Update frequency / maturity

One element that should continue to be represented as different channels is the maturity and/or update frequency of the images. There are currently four levels of maturity:

  • devel-proposed: images land in this channel as soon as they are produced and have not been validated.
  • devel: images are copied into this channel from devel-proposed only once verified by QA. No limits on update frequency.
  • rc: images are copied to this channel from devel after a more rigorous QA process, twice a month.
  • stable: identical to the rc channel, but images are only copied to this channel once a month to limit the frequency with which updates are pushed to end users.

In addition there is presently a channel ubuntu-touch/ubuntu-rtm/14.09-factory-proposed which exists to support landing critical fixes for the vendor. It is recommended to map this to 'ubuntu-touch/rc-proposed' and to support configuring this channel to pull from short-lived distribution branches as required.

Partner-specific "custom" tarball

Channels delivered over-the-air to devices sold to end users may contain different software than that included in the default community image, including software that is not Free Software. Each custom tarball should have its own channel; and all devices within a given channel should use the same custom tarball.

Examples of the kinds of custom tarballs that need to be supported as separate channels include the default "custom" tarball for the Ubuntu community edition; the BQ "international" (i.e., English) custom tarball; and the BQ Spanish custom tarball.

Device-specific channels

As Ubuntu Phone scales out across multiple devices with partners, there will be increasing demand for device-specific content. For example, there are two separate custom tarballs for the BQ Aquaris which are specific to BQ as a partner; Meizu will have a different selection of bundled apps and thus a different custom tarball. It does not make sense to provide a build for Meizu devices with the BQ custom tarballs or vice-versa.

However, in order to decouple hardware-specific bugs from custom-tarball-specific bugs for analysis and debugging, it is recommended to:

  • include each supported device in the default community channel;
  • include reference devices in each partner-specific custom channel (currently, the 'mako' and 'generic' devices); and
  • if possible for the custom tarball in question, include the 'generic_x86' reference device.

This ensures that it will always be possible to test each supported custom tarball in a virtualized environment, and also test each device against the reference community build. It does not completely eliminate the need for integration testing with the target build on the target device, but will enable us to detect most bugs early and at scale without reliance on scarce hardware.

The presence of each of these devices in a given channel does not mandate any particular level of QA for image promotion. Particularly on channels with custom tarballs, it is more important that devices be promoted in lockstep than that the reference devices receive extensive QA, so that the promoted images for reference devices are useful for regression analysis.

Unsupported

Per-distro-series channels

In the model described above, there are no channels that map to specific Ubuntu distribution series (or Ubuntu derived distribution series). This is a deliberate choice; the update model for the phone presupposes continuous updates to the current supported release, and not a conscious decision by the end user to opt in to a release upgrade. There is therefore no reason to expose distribution series names in the channel names, as phone users will never "switch" between channels to accept an upgrade.