Proposal for new charm policies.

[Jorge O. Castro]

Hi everyone,

As we move closer to UDS I'd like to bring up some policy updates with everyone:

https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-charm-policy-review

Currently the folks in Canonical IS have a list of things they
determine whether a charm is suitable for production. I think it's
useful to consider some of these policies as charm store policies. If
something is _too_ opinionated then I'm going to start adding a "Best
Practice" section to the docs.

Specifically I'd like to propose these 5 things to move into policy:

- 3 acks for charm reviews before a charm is considered "reviewed" in the store.

Now that we're getting more mature we need to keep the charm quality
high. So along with landing charm testing we'd like to start doing
more peer review on incoming charms.

- bits should be installed to /srv

Yay FHS.

- Create nagios checks and not which things are critical to monitor.

This bullet is now confusing to me, I think we mean monitoring instead
of explicitly saying Nagios, I'll let Matt or Tom weigh in here to
clear up this one.

- Charm updates must maintain backwards compatibility. A charm should
provide a means for a user to specify the upstream version and
maintain backwards compatibility.



--
Jorge Castro
Canonical Ltd.
http://juju.ubuntu.com