charm teams

Mark Mims mark.mims at
Wed Mar 13 16:14:01 UTC 2013

Hey gang,

Pecking away at the queue this week made me realize that the time has
come for us to put together more teams of charmers...  i.e., teams
dedicated to managing particular charms or sets of charms.

A perfect example of this is the postgresql charm.  We've had a lot of
activity on that charm recently... to take it from the placeholder we
had before to a charm that creates a range of production-quality
postgresql services.  It's been great to see, but it's one of those
situations where we (~charmers) have been blocking progress because of
the amount of time merge-proposals sit in the queue.  

To streamline that process, we've discussed creating teams like
`~postgresql-charmers` and making


the official branch in the charm store.  We'll add the `~charmers` team
to the `~postgresql-charmers` team so anyone in either team can push to
those branches.  This way, MPs/bugs can be addressed by a member of
either team.

One potential negative ramification of this is that since we are
diluting the set of people responsible for maintaining charm quality, we
might start diluting charm quality.  In practice, I think this will
result in quite the opposite outcome.  Stuart Bishop shouldn't be
waiting on me to review his postgresql-related code ;)

I suspect we could put together 6-12 different teams _today_ based on
queue activity over the past couple of months.

Ok, so what am I missing here?  The biggest unknown is the charm-store
behavior itself.  In lp, we can point 

    lp:charms/postgresql to

just as easily as we've been pointing

    lp:charms/postgresql to

but it seems the charmstore code doesn't use those lp aliases and just
looks directly at the `~charmers`-owned branches.  Can anyone clear that
up?  If so, how much work is it to include team-owned branches as
"official" in the store?


Mark Mims, Ph.D.
Ubuntu Server Team
Canonical Ltd.
mark.mims at

More information about the Juju mailing list