Re: [Ubuntu-phone] Archive management plans for phone RTM
Le 11/06/2014 05:21, Colin Watson a écrit :
* replacing the /ubuntu/ part of ppa.launchpad.net URLs
* parameterising the various places that the ubuntu distribution is
hardcoded in cupstream2distro/launchpadmanager.py
1. The only place this needs to be changed is at:
def get_ubuntu():
'''Get the ubuntu distro'''
lp = get_launchpad()
return lp.distributions['ubuntu']
All the get_series() and other functions are first calling get_ubuntu().
2. The other place that will need change is:
citrain/merge-clean:ppa_base_path =
http://ppa.launchpad.net/{}/{}/ubuntu/dists/{}/main/.format(ppa.owner.name,
ppa.name, series.name)
Where we check that the ppa is really empty.
3. Apart from changing the set of ppas to be based on this new
distribution and the destination copy (can we retarget the existing
ones, maybe?), that will be all I think.
Cheers,
Didier
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Ubuntu-phone] Archive management plans for phone RTM
On Thu, Jun 05, 2014 at 12:10:25AM +0100, Dimitri John Ledkov wrote: On 4 June 2014 21:20, Colin Watson cjwat...@ubuntu.com wrote: Any other questions? Will PPAs be enabled on the derivative distribution, such that if I wish/need I can build packages in the PPA against the RTM suite. Yes, there's no particular reason not to, and they'll have to be in order for the CI engine to work. -- Colin Watson [cjwat...@ubuntu.com] -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Ubuntu-phone] Archive management plans for phone RTM
On Wed, Jun 4, 2014 at 1:20 PM, Colin Watson cjwat...@ubuntu.com wrote: The current plan is therefore: * Rick has asked me to take ownership of deciding when to branch for RTM; note that this decision can be taken retroactively by copying older versions of packages, so we can say the image from three days ago looked good but things have been broken since then, so let's branch from that. I intend to take this decision based on how stable images are and how much tension there is between phone work and development of other parts of Ubuntu; Another factor that should feed into this decision should be the schedule/status of our currently ongoing commercial engagements with our phone OEMs, as they will be another constituency for whom minimized tension/disruption will be critical around that time frame. * We will then have an ubuntu-phone (name TBD) distribution in Launchpad with a series named something like rtm-14.09, and will land changes for RTM there, allowing other parts of Ubuntu to move on without risk of breaking phone images. We'll have a -proposed pocket as usual and proposed-migration will operate on it. I'd like permissions on this distribution to be identical to those in Ubuntu where possible, but we can discuss details there. There'll be system-image channels for RTM, probably per-device. The probably per-device clause is interesting. Noting it here to feed into questions below. * We don't want to have to maintain RTM series for a long time. The plan is to move devices to the next stable branch along as soon as possible. To facilitate this, the usual rule should be that changes should only go into this distribution after they're already on their way into mainline Ubuntu (as for SRUs), to make sure that we don't end up in a situation where developers land changes on the stable branch but don't quite get round to landing them in mainline. Agreed that this policy is critical to the long term success of Ubuntu phone images, as reducing/eliminating rootfs fragmentation is one of the key differentiators of our platform vs. Android. = FAQ = 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'. I assume the probably per-device channel mechanism could be used here? A simplifying assumption is that the commercial downstreams will definitely want to follow the policy of mainline first and have devices-in-the-field update from next stable branch ASAP, although be aware that the value of P may be on the order of multiple months. 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. We can make the nightmare worse by imagining that it inexplicably occurs 6 months after initial shipment. Thanks. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Ubuntu-phone] Archive management plans for phone RTM
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] -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
