Juju Charm submission Workflow

Registered by Jorge O. Castro on 2011-10-18

How are we going to manage community submitted charms? Peer review? etc.

Blueprint information

Status:
Not started
Approver:
Jono Bacon
Priority:
Medium
Drafter:
None
Direction:
Approved
Assignee:
Jorge O. Castro
Definition:
Approved
Series goal:
Accepted for precise
Implementation:
Not started
Milestone target:
milestone icon ubuntu-12.04

Related branches

Sprints

Whiteboard

Charms to write

https://docs.google.com/spreadsheet/ccc?key=0AoW1nhI7IMt3dFRvSFdkZmNqQ0t3RjZ2QTR2Z19teWc

Charmers
What does “charmers” mean - commit access to lp:charm

What should “charm-contributors” DO -

- Write charms
- Review new charms
- Triage charm bugs
- Mentor new charm contributors and users
[jorge] Jorge to take in changes from the community and update the wiki until the "real" juju.ubuntu.com launches.: DONE

What SHOULD “charmers” DO -

- Approve new charms
- Charm store maintenance
- Fix release critical charm bugs
- Have access to launchpad.net/charms

Inclusion process for “charmers”:
- Sign Ubuntu Code of Conduct
- Two +1’s from existing charmers
- Guideline: have demonstrated understanding of charm store policy

What about ownership? upstreams? "<upstream> Charmers" groups

How do package sets work for lp:charm?

Releases

* What does “oneiric” mean in “charm”
 * Stable charms as of “some release date” + updates “cs:oneiric-stable” == cs:oneiric
 * “latest” charms continue to go to cs:oneiric-latest
* whole release copied to new dev series
* Automated tests for backporting to all previous series “latest” pocket, also stable if charm is “NEW”
* series just means “we’ve seen this charm run on that release of Ubuntu”
* PLANS: oneiric releases when charm store backend is complete
* PLANS: precise release together with 12.04
* ACTIONS
  - define implementation of backend service understanding “stable” vs. “latest”
  - develop or identify tools for managing release (copy all branches to new stable, tagging, etc)

Classification ( used to be "Components" )

Charm: freeness, distributableness, visibility, reviewed, testing
Included Bits: freeness, distributableness, repeatable
Additional Tags (upstream, stable, tip,...)

Why classify your charms?
1) Trust, safety net, tested, QA’ed, well known peer review by experienced charmers.
2) Self contained and won’t go away
3) Will get security and critical updates (similar to the distro)
Author needs to classify the “level” of a charm, is it a mess around “+junk” or is it something that you can push to production?
“These are the charms you don’t have to read”
some charms can provide an audit trail

Work Items:
[clint-fewbar] Update juju.u.c/Charms: DONE
[jorge] Jorge to take in changes from the community and update the wiki until the "real" juju.ubuntu.com launches.: DONE
[jorge] Talk to IS about how we can give community people write access so they can fix docs, document their interfaces, etc. without pwning juju.u.c.: DONE

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.