charm-helpers fixes, how to merge them into actual charms?

[Christopher Glass]

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 <andreas at canonical.com> 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
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>