On Wed, Jun 04, 2014 at 06:27:36PM -0700, Alex Chiang wrote: > On Wed, Jun 4, 2014 at 1:20 PM, Colin Watson <cjwat...@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 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 [cjwat...@ubuntu.com] _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
