New policy proposals (take 2)

[Jorge O. Castro]

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.
http://juju.ubuntu.com