launchpad-dev team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

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@xxxxxxxxxx> 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
rtm-14.09-updates.

> 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@xxxxxxxxxx]