Charm Store <-> Ubuntu Release policy, part deux

[Clint Byrum]

We had a great discussion in #juju earlier today that resulted in some
clarification on how we'd like the charm store and charm development to
work out, so I wanted to send it to the list for wide spread comment.

---
Charm Store / Ubuntu Series
---

Charms should be pushed to the series branch that represents where the
charm has been tested and is known to work. We are not going to trust our
automated tests alone to dictate this, its up to the maintainer and the
charmers team.

---
Essential Charms
---

At UDS, we will discuss what charms we think are essential for all
releases of Ubuntu, and ~charmers will work to make sure these charms
are always tested and pushed forward to every release.

---
Work flow
---

1. If you developed your charm on precise, then it should be pushed to
lp:~youruser/charms/precise/yourcharm/trunk. This will end up in the
official charm store as cs:~youruser/precise/yourcharm.

2. After review, if the charm is an officially approved charm, a
charmers member should push your changes into the official charm branch
at lp:charms/precise/yourcharm. If you are a member of charmers, you can
skip step 1, but its recommended that we keep doing reviews on anything
except minor fixes/doc changes to keep charm store quality high.

3. If you test your charm on quantal, and it works, these changes
should then be pushed to lp:charms/quantal/yourcharm. If there is no
official lp:charms/quantal/yourcharm yet, launchpad will create it at
lp:~pushuser/charms/quantal/yourcharm/trunk.  This is fine, but note
that this path is not safe as the "official" path because if a charmers
member needs to fix something in your charm, they will have to push to
lp:~charmers/charms/quantal/yourcharm/trunk and then "charm promulgate"
that to make it the official version.

---
Dev Focus, or lp:charms/foo
---

The dev focus will remain on the latest LTS. This is the predominant
choice for server users as a platform, and unlike distro packages,
will likely be where the bulk of charm dev happens. Our current policy
defines how changes to charms in stable releases are goverened, and it
should prevent rampant regressions.

The dev focus will be moved forward to the next LTS very early in its dev
cycle to encourage new charms written at that time to land in the new LTS.

---
Why is sthis different from the way Ubuntu does packages?
---

Charms do not have the same level of dependency specification that
debs do.  We can't say "needs at least mysql 5.5" in a charm metadata
(yet?). So, the series is all we have, and a charm can basically declare
that it is ok with all the deps in a series by existing there.