Clarifying Charm Store policy around Ubuntu Releases
Rationale:
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.
Goal:
A policy that informs users how Charms will be managed in Ubuntu releases.
Blueprint information
- Status:
- Complete
- Approver:
- Antonio Rosales
- Priority:
- High
- Drafter:
- Ubuntu Server
- Direction:
- Approved
- Assignee:
- Clint Byrum
- Definition:
- Approved
- Series goal:
- Accepted for quantal
- Implementation:
-
Implemented
- Milestone target:
-
ubuntu-12.10
- Started by
- Antonio Rosales
- Completed by
- Clint Byrum
Whiteboard
Topics:
* 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.
backports?
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
WORK ITEMS?
----
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.
Assumptions:
* 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.
