ChannelSchemaSpec

Differences between revisions 2 and 13 (spanning 11 versions)
Revision 2 as of 2015-03-05 05:25:57
Size: 1360
Editor: vorlon
Comment:
Revision 13 as of 2015-04-01 16:51:46
Size: 6645
Editor: vorlon
Comment: tweak the rules on reference devices in channels, per PES feedback
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
=== Carrier-specific "custom" tarball === 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 the 'generic' device in each partner-specific custom channel;
 * where permitted by the licensing agreement, include the 'mako' reference device in each custom channel; 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.
Line 18: Line 36:
=== Device-specific channels === == No 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. Timing of updates for a given device may vary and be dependent on acceptance of the build by a partner, but there will only be one update stream offered to all partners and no support for a per-release update stream.

This assumes that, for any given partner engagement at any given time, there will be at most two distro series in flight: the "devel" series, providing new image updates through the '''devel-proposed''' channel; and the "stable" series, providing new image updates through the '''rc-proposed''' channel.

At any given time, the '''ubuntu-touch/devel-proposed/ubuntu''' channel (which will contain the generic community builds) should pull from the current Ubuntu development series. The corresponding partner-specific channels do not necessarily point to this same series at all times. For instance, in the run-up to the BQ launch, the hypothetical '''ubuntu-touch/devel-proposed/krillin.en''' channel might have been configured to pull from ubuntu-rtm/14.09 since that is where development for the initial product release was targeted, while '''ubuntu-touch/rc-proposed/bq-aquaris.en''' would be configured to pull from ubuntu-rtm/14.09-factory.

This limits the usefulness of the '''ubuntu-touch/devel-proposed/ubuntu''' vs. '''ubuntu-touch/devel-proposed/krillin.en''' channels for isolating bugs in custom tarballs, but is traded off against the need to manage a larger number of channels. This trade-off should be re-evaluated once we have gathered experience with the proposed model.

== QA of image vs. custom tarball ==
The existing '''devel-proposed''' channels are used for validating new versions of the system and device tarballs. Because the per-vendor custom tarballs are prepared by a process outside of the Ubuntu archive, it is important to be able to validate these in a separate pass that doesn't entangle custom tarball promotion with system image promotion. This is currently done through a series of '''-proposed-customized''' channels. Going forward, it is recommended to instead use an additional -proposed suffix on the device-specific channel name: e.g. '''ubuntu-touch/devel-proposed/krillin.en-proposed'''.

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 the 'generic' device in each partner-specific custom channel;
  • where permitted by the licensing agreement, include the 'mako' reference device in each custom channel; 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.

No 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. Timing of updates for a given device may vary and be dependent on acceptance of the build by a partner, but there will only be one update stream offered to all partners and no support for a per-release update stream.

This assumes that, for any given partner engagement at any given time, there will be at most two distro series in flight: the "devel" series, providing new image updates through the devel-proposed channel; and the "stable" series, providing new image updates through the rc-proposed channel.

At any given time, the ubuntu-touch/devel-proposed/ubuntu channel (which will contain the generic community builds) should pull from the current Ubuntu development series. The corresponding partner-specific channels do not necessarily point to this same series at all times. For instance, in the run-up to the BQ launch, the hypothetical ubuntu-touch/devel-proposed/krillin.en channel might have been configured to pull from ubuntu-rtm/14.09 since that is where development for the initial product release was targeted, while ubuntu-touch/rc-proposed/bq-aquaris.en would be configured to pull from ubuntu-rtm/14.09-factory.

This limits the usefulness of the ubuntu-touch/devel-proposed/ubuntu vs. ubuntu-touch/devel-proposed/krillin.en channels for isolating bugs in custom tarballs, but is traded off against the need to manage a larger number of channels. This trade-off should be re-evaluated once we have gathered experience with the proposed model.

QA of image vs. custom tarball

The existing devel-proposed channels are used for validating new versions of the system and device tarballs. Because the per-vendor custom tarballs are prepared by a process outside of the Ubuntu archive, it is important to be able to validate these in a separate pass that doesn't entangle custom tarball promotion with system image promotion. This is currently done through a series of -proposed-customized channels. Going forward, it is recommended to instead use an additional -proposed suffix on the device-specific channel name: e.g. ubuntu-touch/devel-proposed/krillin.en-proposed.

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