On 07/06/12 09:15, Vincent Ladeuil wrote: >>>>>> Max Bowsher <_...@maxb.eu> writes: > > An LXC just for this feels like an overengineered solution to me. > > Maintaining a single lxc container config file is less work than > backporting a growing number of packages. > > It has the benefit of isolating the importer into its own container > allowing us to rely on packages specifically targeted to our needs when > needed without requiring inclusion in -cat archives and brings us closer > to the platform used by packagers *avoiding* many failures. ...
> I.e. using an lxc container allows us to migrate to quantal *now* > whereas jubany will get precise... at an unknown date. It also means > that when pristine-tar is fixed upstream we get it more quickly deployed > with minimal effort. > > I'd rather rely on the ubuntu community to keep the packages we need > up-to-date than dealing with a growing list of packages that need to be > backported by a smaller team. Right, I agree we should use stuff straight from Ubuntu when we can, but I don't agree that it's necessarily wrong to customize our deployment practices to get fixes faster. In particular, I've been pinged on IRC about whether we can fix a couple of these packages soon, and it seems to me that I could do just that - and do it this weekend - by installing new xz and pristine-tar versions just for the importer. So I'd quite like to do that. > backporting pristine-tar is not enough, xz-utils is also needed, with > its own dependencies. It can't be *that* onerous, can it? :-) > Moreover, we want to hand over the deployment to > Canonical ops so adding more manually installed dependencies doesn't > seem to go in the right direction. OK, this is going to be controversial, but.... I don't think we should be planning to hand the deployment over to Canonical Ops any time soon. The needs, and bugs, of the importer still seem to be evolving at a pace where retaining full control in the hands of those with domain specific knowledge seems to be a far far better option than enforcing a Dev vs. Ops divide. > Don't get me wrong, I *did* push to get to the point where we could use > branches for bzr and bzr-builddeb (let's ignore distro-info...) but I'd > prefer to draw the line there, these are packages we are upstream for > and it makes sense to be able to quickly deploy fixes if only to test > them before official releases are cut. On the other hand, we're (one of?) the primary consumers of pristine-tar, so it's not really much of a stretch. And it provides better service to Ubuntu developers if we can turn around an upgrade of that sort of thing without communication across a Dev/Ops boundary. Max.
signature.asc
Description: OpenPGP digital signature
-- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
