Clarifying Charm Store policy around Ubuntu Releases

Registered by Clint Byrum

The charm store has only been around for one release, so we're still learning how it relates to releases of Ubuntu. Also the LTS is likely a desired target for the next 2 years for conservative users. Thus, there is a need to start putting policies around the Charm store so users will know what to expect and how to interact with Charms across Ubuntu releases.

A policy that informs users how Charms will be managed in Ubuntu releases.

Blueprint information

Antonio Rosales
Ubuntu Server
Clint Byrum
Series goal:
Accepted for quantal
Milestone target:
milestone icon ubuntu-12.10
Started by
Antonio Rosales
Completed by
Clint Byrum

Related branches



* When do we advance the charms dev focus to each new release of Ubuntu
* Should we auto backport and forward port charms, if so, how?

Charm Store Policy

- This is a living policy, we will not try to get it perfect, so trying to get it perfect is not useful, we need to be agile and revisit our policies on a regular basis.
- Charm Store doesn't freeze
- I want stability. I want a single place to collaborate around.

charm store submissions?
When to "open" the next release series?

Where we've been doing:

- Default series is LTS with "juju deploy foo"

Where do we want to go with it:

- Default series should be LTS with "juju deploy foo"
- Search should default to the best possible solution first.

what do we mean by:
 - open - able to push to this series
 - development focus - default series to build against?

dev focus with release (at beta?)
but insure lts gets as much focus as we can

one approach
- commit to latest dev focus
- try to test on previous release
- try to test further back
two things to do this:
- blacklisting for tests
- better automated testing

also start forward testing as soon as alpha1 is available

perhaps charm browser can show test status for each charm... _per release_

security is an aspect of this when considering preventing, allowing, or automating back-ports
maybe don't auto-backport...
put on the maintainer's shoulders?
what about use tags?... auto-backport only tagged appropriately?
(kinda like "pockets" security, etc etc)

Tags for charms to denote default behavior

perhaps the only valid tags we can use are ones that can be automatically tested?

we digress...

we branched too late for precise release
next time... ?
  - q the dev focus on beta1 day?
  - what to do with backports?

hard problem, we don't have solid answers...
maybe we just need to make a decision and run with it

follow the distro model, but lag by three months
adjust on demand

Dev focus to stay on LTS (precise) and push promulgated charms forward and test forward



User Stories:
* Jesse's Charm is in 12.04 and he would like a clear understanding of how his Charm will progress in the Charm store when 12.10 is released.
* Andrew has he charm included in 12.10 charm store and would like to know what the policy is for that charm being included in 12.04.

* This is a living document that can be adjusted based of feedback, and experience.
* Launchpad is technically able to manage Charms outlined in the policy.

Test Plans:
* Document and implement policy. Get feedback from users.

Release Note:
* Add information on where the The Charm Store Policy can be read.


Work Items

Work items:
Author and communicate proposed release plan to juju mailing list: DONE
revisit charm store release policy on juju mailing list: DONE
(Placeholder) Implement testing plan after discussion: POSTPONED
(Placeholder) Implement release plan after discussion: DONE
(Placeholder) Verify Launchpad can support release plans/policies: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.