Charm derivation

[James Westby]

On Mon, 16 Jan 2012 19:28:23 -0200, Gustavo Niemeyer <gustavo.niemeyer at canonical.com> wrote:
> >> These sound like normal requirements for any relevant charm regardless?
> >
> > You mean any generic charm, or any charm at all? I don't think that the
> > wordpress charm maintainer will have to deal with requests to add a
> > hadoop interface.
> 
> What I meant is that I also expect the wordpress charm maintainer to
> have changes cross-reviewed by other interested parties.

Right, but I don't think they will have the same problem with having to
remember why someone three years ago asked for the generic charm to
support $interface for their private project that they can't really talk
about. The wordpress maintainer has some idea of what the wordpress
charm has to do, but the generic charm maintainer doesn't as it's a
charm that gets its purpose from how it is deployed.

> > "use [...] merely as a guideline" is what I want to avoid. People are
> > going to all of this hard work to support all these web frameworks, and
> > then those of us with slightly unusual requirements only get guidelines
> > out of it?
> 
> That's a good point. If there's some very nice logic being developed
> for a specific framework, there's no reason to be duplicating it
> everywhere, and the way to do that is quite usual: get that logic in a
> common location (branch, package, etc) and base charms on it.

That's exactly what I'm asking about, how should I go about doing this?

Thanks,

James