|Deletions are marked like this.||Additions are marked like this.|
|Line 41:||Line 41:|
This limits the usefulness of the '''ubuntu-touch/devel-proposed''' 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.
Table of Contents
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.
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.
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.
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 channel (which contains the generic community builds) should pull from the current Ubuntu development series. The corresponding partner-specific channels do not necessarily point to this 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 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.