Realigning charm workflow to match Ubuntu
clint at ubuntu.com
Tue Feb 28 22:28:28 UTC 2012
Excerpts from Jorge O. Castro's message of Tue Feb 28 13:40:35 -0800 2012:
> Clint, Mark Mims, and I started talking about this on the phone but
> think it's better to have the discussion here to get more opinions.
> Right now we're not using merge proposals for charms, we ask people to
> file a bug and manually attach a branch, then we ask people to tag it
> with "new-charm" and we do a review and move on.
> This is a bummer for a few reasons, one that is particularly annoying
> is that we are different from other Ubuntu projects, so we can't
> lovingly steal documentation or tools that other people are using.
> Surely someday we'd like to have tarmac autoland fixes to charms as
> they come in or whatever.
> When we started we found a problem with being able to handle new
> charms with the existing Launchpad MP process. (Clint, insert your
> explanation here). I'd like to revisit that and bring it up for
> discussion again because I'd like to not be the odd one out.
So the only real thing preventing us from using Merge Proposals is that
when new charms are created, there is no branch for people to propose
I don't have a good answer for this, but I don't know that using merge
proposals for new charms will really benefit the process that much,
and might end up adding complexity to it.
For all changes to the official charms, I do think we should use merge
proposals, and many of us already have.
As somebody who does these reviews and uses the process, I don't find
it at all unpleasant, with very few manual steps. I do think that the
charm store will change this even more, and so we should probably defer
this discussion until it is available.
More information about the Juju