ChannelSchemaSpec

Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2015-03-04 16:22:52
Size: 545
Editor: vorlon
Comment:
Revision 5 as of 2015-03-06 00:49:23
Size: 2965
Editor: vorlon
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:

== 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.

=== 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.

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.

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.

Touch/ChannelSchemaSpec (last edited 2015-04-01 16:51:46 by vorlon)