[Ubuntu-phone] Archive management plans for phone RTM

Colin Watson cjwatson at ubuntu.com
Thu Jun 5 02:29:34 UTC 2014

On Wed, Jun 04, 2014 at 06:27:36PM -0700, Alex Chiang wrote:
> On Wed, Jun 4, 2014 at 1:20 PM, Colin Watson <cjwatson at ubuntu.com> wrote:
> > Can we use this strategy for other Ubuntu flavours or derivatives?
> >
> >   In theory, maybe.  It's very much easier to use this strategy for
> >   phone images, though, because the standard distribution mechanism is
> >   via system-image channels so we don't need to worry about updating
> >   sources.list or arranging for mirroring of the derived archive, etc.
> >   There's also a potentially serious social cost to having lots of
> >   archive branches, and I wouldn't want to do so except for short
> >   durations under tight management; I don't want to see the
> >   Ubuntu-and-flavours development community fracturing unnecessarily.
> Will this mechanism be able to support an arbitrary number of
> commercial downstream flavors? My assumption here is that a commercial
> downstream will branch off RTM itself, forming RTM'.

Possibly, but it's rather heavyweight and I don't know how well it would
scale to lots of them, so I'd prefer not to do too many like that at the
moment.  Just layering a PPA on top should do for most such cases and
makes it easier to keep the downstreams up to date, which I gather we
probably want to do anyway.  With suitable use of apt pinning during
image building we could even provide a simple mechanism for downstreams
to elect to hold back a given package, without them having to
micromanage everything.

> I assume the "probably per-device" channel mechanism could be used here?

Right, but you do need an archive or combination of archives to build an
image from.

> Will there be some mechanism to recreate the archive at the RTM or
> RTM' branch point? I am thinking of a factory hotfix nightmare where
> access to the exact source / package versions will be critical in
> debugging the issue.

I think we could use most of the same script that we'll need to use to
do the initial branching to recover the RTM branchpoint and republish it
somewhere else; we just need to keep the manifest or datestamp or
whatever.  Similarly the same kind of thing would work on a slightly
different axis for what you're calling the RTM' branchpoint, if suitably
parameterised.  Once it's written I'd been planning to put the script in
lp:ubuntu-archive-tools for convenient access.

(I suppose it would also be possible to create artificial branchpoint
series to act as tags, but I think that's overkill; that could end up
being a significantly larger set of binaries to keep live on the
publishing system when we really just need to be able to republish them
as a contingency plan.)

We should think about when to mark the rtm-14.09 (or whatever) series as
"Current Stable Release" in LP, since that would provide a simple GA
kind of tag without much effort, and everything after it could go into

> We can make the nightmare worse by imagining that it inexplicably
> occurs 6 months after initial shipment.

For Ubuntu this is fine because we don't garbage-collect pre-release
binaries from development series until well after the point anyone is
going to care about them.  For RTM I'd need to check what the GC policy
would be.

Colin Watson                                       [cjwatson at ubuntu.com]

More information about the Ubuntu-release mailing list