>>>>> Max Bowsher <_...@maxb.eu> writes:
> On 06/06/12 13:43, John Arbash Meinel wrote:
>> We're trying to work with webops to get Jubany at least upgraded from
>> Lucid to Precise,
> Great, what's the estimated timeline for that?
Unknown.
>> and then follow it up with something beyond that.
>> We're considering trying to get an LXC running Q, or maybe just
>> backporting Q's pristine-tar for precise.
> 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.
To put numbers in perspective, the pristine-tar import failures are
currently (well, were a week ago, new ones appeared on a weekly basis in
the last year):
- 327 on jubany (lucid + some backports)
- 275 on precise
- 147 failures on quantal
One way to look at it is to say that 180 failures were caused by the
constraint to run lucid on jubany. backporting pristine-tar will also
left 147 pending failures waiting for a fix that itself will require
another backport or two.
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.
Now, if we can't use quantal, a precise lxc container where we can use a
dedicated ppa will still reduce the backport work while still freeing us
to respect Canonical ops constraints on them (backporting to lucid-cat
means the backport should work for *all* machines in the DCs).
> Even backporting Q's pristine-tar to precise puts Canonical Ops on the
> critical path, whereas we could avoid that by doing what we've done for
> bzr itself and install a suitably recent version just for the pkg_import
> user.
backporting pristine-tar is not enough, xz-utils is also needed, with
its own dependencies. 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.
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.
Vincent
--
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
