The Juju Charm Store
Juju includes a collection of what we call '''Charms''' that let you deploy whatever services you want in Juju. Since charms are open and worked on by the community, they represent a distilled set of best practices for deploying these services.
- The main distro page is here: https://launchpad.net/charms
- There are useful tools for downloading, modifying, and contributing here: https://launchpad.net/charm-tools
- Here is the official tutorial for charm writing: https://juju.ubuntu.com/docs/write-charm.html
Charm Store Process
This process is designed to allow prospective developers to have their charms reviewed and updated in the Charm Store in a timely manner that ensures peer reviews and quality.
Submitting a new Charm
- Install juju and charm-tools.
- Create a repository, something like mkdir -p ~/charms/precise, precise is the release code name for the release of Ubuntu you wish to target your charm at.
- If you haven't created your charm yet, you can use charm create ubuntu-package-name which will fill in some basic metadata info for you. You can check to see if it already exists at http://jujucharms.com/. Also make sure to check the list of open charms to see if anybody is already working on a charm for the service you want to work on. Bugs which have had no activity by the assignee for more than 30 days are fair game and should be unassigned.
- Once your charm is working and tested with any compatible charms, make sure it passes charm proof path/to/your/charm
- bzr init in your charm's root directory
- bzr add to add all files.
- bzr ci -m'Initial charm'
- bzr push lp:~your-launchpad-username/charms/precise/your-charms-name/trunk
- File a bug against charms at https://launchpad.net/charms/+filebug This is used to track the progress of your charm.
- Subscribe the charmers team by clicking "Subscribe someone else" on the right side of the launchpad page. This is important as it gets your charm in the review queue!
Your charm should then be looked at in a timely manner.
Submitting a fix to an existing Charm
- Grab the charm you want to fix, we'll use Nagios as an example: bzr branch lp:charms/precise/nagios
- Modify it to meet your needs.
- Commit your fixes bzr commit -m'Your changelog entry goes here'
- bzr push lp:~your-launchpad-username/charms/precise/nagios/fixed-charms-name
- Submit a merge proposal by going to the charms code page: https://code.launchpad.net/~charmers/charms/precise/nagios/trunk and clicking "Propose for merging"
- In the merge proposal form paste in the fixed-charms-name that you pushed to earlier.
- For the reviewer field put the charmers team, this will get your code into the review queue!
Getting Help
Inspired by Bazaar's Patch Pilot programme there will be patch pilots in #juju who can help you get your patch accepted. Check the topic to see who's on duty. Still need help? Poke us on the mailing list ; if you're from an upstream project who wants more detailed help/tutoring, then contact Jorge Castro and we'd be more than happy to get a charm expert to help you out or help you run a Charm School.
Some notes:
- Please respect that these people might have a few other charms in their queue already.
- The package you have a question have about might not necessarily be part of the patch pilot's area of expertise. They will still try to help you get your fix in and probably get you in touch with the 'right' people.
Reviewers
Modify the topic in #juju to put yourself down as the reviewer for your shift.
Check out the review queue and be responsive on IRC for user questions.
Review the items in the queue. If the queue is caught up and not on fire, consider the following tasks:
- Answer questions on IRC, the mailing list, and the juju tag
- Work on the documentation
- Work on simple proof errors
- Triage bugs in lp:charms
When your shift is over modify the topic in #juju to put ~charmers as the reviewer. (When no one is specifically assigned to review we just default to ~charmers).
(Optional) Send a mail to the juju list summarizing your shift, new charms you might have promulgated or updated, issues that might have been raised by the review, or anything else you feel you should share with the community.
Here's the Calendar for reviewing if you want to check what day you have.
Review Tips and Criteria¶
- Expectations:
- The goal is to welcome the contributor and help them have a good experience getting fixes into Ubuntu; your first response should be to thank them profusely. By making collaboration easier, we can hope to see more contributors and thus lighten the development workload on everyone. This is important for a number of reasons:
- We want to be a welcoming community.
- With every word of thanks you encourage new contributors and give them more confidence, which is very important, as our part of the community is sometimes hard to understand or look into.
- We want to make our whole development experience social. We not only want contributors, but team mates.
- Tips:
- Start your review by saying "Thanks", no matter what the outcome of the review is going to be.
- If you recognise somebody you've worked with on IRC, thank them.
- Consider blogging about a particularly nice contribution. This will not only make the contributor feel valued, but also inspire others with a good example of great work.
- Encourage contributors to apply for ~charmers if you think they're ready.
- If the merge proposal or patch requires more work, encourage the contributor to join #juju and discuss the solution there.
- Follow these instructions as well as you can.
- Good tips:
- If this is your first time patch piloting, you may feel more comfortable being a co-pilot your first few runs. Find a pilot in your timezone and reschedule your time to coincide with theirs.
- ''Optional:'' Send a brief mail after your stint, to say what you did and how it worked out. If you have feedback on the review system or the process, speak up.
- You're not obliged to deal with all the open patches. We appreciate what you do do.
- You can prioritize whichever you think best achieves the goal of helping people enjoy getting things done in Juju. That might be the newest ones, neglected patches, easy patches, or those from new contributors. The Review Queue sorts by age.
- If you are unfamiliar with the package, make sure you review everything you can, it's not necessarily your job to merge/promulgate it. If, after you did your review, you can get the contributor in touch with somebody who knows the codebase better, you already helped out a lot.
Sponsorship is organized into
If something needs review, subscribe ~charmers.
You can see the currently pending requests at:
- https://bugs.launchpad.net/charms/+bugs?field.subscriber=charmers
- https://bugs.launchpad.net/charms/+bugs?field.subscriber=charmers&field.component=3&field.component=4
- http://manage.jujucharms.com/review-queue
Charm Inclusion Policy for Reviewers
Please see the official Charm Store Policy document.
Join Us!
We also need help reviewing and testing charms. The Charmers team is granted write access to the Charm Collection and charm-tools. If you'd like to join that group, here are some tips:
- Join charm-contributors ! You will immediately be able to help out with bug prioritization.
- Join the discussion on IRC (Freenode) in #juju and on https://lists.ubuntu.com/mailman/listinfo/juju
- Test charms and report your successes or file bugs.
- Write charms - pick a web app or a backend technology and write a charm.
- Review new charms https://bugs.launchpad.net/charms/+bugs?field.tag=new-charm
Upon getting involved with these activities, we'll probably ask you if you'd like to join charmers. If not, go ahead and apply for membership to the team, and send an email to the list letting us know about your reasons for wanting to be a member of charmers.