For the record, we can easily send branches against charms that matter to us for this particular case (as we will for few other landscape-owned branches waiting for review [1] [2] [3], hint hint :) ).
But this seems like a problem in need of a more general (and scalable) solution. - Chris (tribaal) --- [1]: https://code.launchpad.net/~tribaal/charm-helpers/charm-helpers-fix-exception-when-path-does-not-exist/+merge/218514 [2]: https://code.launchpad.net/~tribaal/charm-helpers/charm-helpers-apt-lock-refactor/+merge/218696 [3]: https://code.launchpad.net/~tribaal/charm-helpers/charm-helpers-fix-apt-cache-race/+merge/219360 On Tue, May 13, 2014 at 3:21 PM, Andreas Hasenack <[email protected]> wrote: > This sounds a lot like the static build problem: once a piece of shared code > is fixed/updated, how to make sure everything using it gets rebuilt? > > charm-helpers is such a case. It's shared code used by a growing number of > charms. > > Case in point: https://bugs.launchpad.net/charm-helpers/+bug/1317980 > > It makes the ceph charm fail when deploying to a machine where a PV is not > part of a VG (pardon the LVM lingo). > > It was merged into charm-helpers. What's the procedure now to get it merged > into at least the ceph charm? And whatever else could be affected? > > For now, I filed a bug against the ceph charm: > https://bugs.launchpad.net/charms/+source/ceph/+bug/1319032 > > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
