<div dir="ltr">+1</div><div class="gmail_extra"> <div class="gmail_quote">On Wed, May 15, 2013 at 11:46 AM, Jorge O. Castro <<a href="mailto:jorge@ubuntu.com" target="_blank">jorge@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok so we had a discussion at UDS, and we've narrowed it down to one policy proposal, and 2 best practice submissions. - [policy] Charms should provide a way, when possible, to pin versions of a software (defaulting to packages, when packages are available - in order to maintain stability between versions of the charm) and the charm has to provide a clean upgrade path (via upgrade-charm) to insure all data created and stored by the charm is maintained from past versions - [best practice, not policy] installation locations should be configurable yet default to standard FHS locations (like /srv) - [best practice not policy] charms should implement relations for common subordinate services such as monitoring, backups, log aggregation, etc... best practice that will evolve as we develop more infrastructure services to plug together and then last one is a "Future policy submission" which we should discuss. Instead of +3 acks, we'd like to: - Gate on tests. - charm has to have non-trivial integration tests ($CHARM_DIR/tests) - passing tests against (preferably all) providers The current problem is that gating on tests isn't currently turned on, but Marco/Mims/GUI team are working on it. -- Jorge Castro Canonical Ltd. <a href="http://juju.ubuntu.com" target="_blank">http://juju.ubuntu.com</a> -- Juju mailing list <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a> </blockquote></div> </div>