Juju Charm submission Workflow
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 Castro
- Definition:
- Approved
- Series goal:
- Accepted for precise
- Implementation:
- Not started
- Milestone target:
- ubuntu-12.04
- Started by
- Completed by
Whiteboard
Charms to write
https:/
Charmers
What does “charmers” mean - commit access to lp:charm
What should “charm-
- 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.
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.