Charm maintainership in metadata.yaml?

[Kapil Thangavelu]

Excerpts from Gustavo Niemeyer's message of Mon Nov 14 18:08:32 -0500 2011:
> >>> Likewise, there will be charms with no maintainer that will
> >>> be handled much like Ubuntu packages, where the maintainer would just
> >>> be charmers at ubuntu.com or something like that.
> >>
> >> I think it would be good practice to have a designated person or LP team
> >> associated with every charm; an overall core charmers team would have a
> >> mandate to amend any core charm, but the charms should all have
> >> designated maintainers rather than being in one single bucket.
> >
> > +1.  In recent efforts to have better/faster initial response to bugs in
> > Ubuntu packages residing in Main, we thought to use the package
> > maintainer to determine which team should be first responder...until we
> > noticed the *heavy* use of the generic "Ubuntu Developers" maintainer,
> > with email pointing to ubuntu-devel-discuss :/.
> 
> +1.  There are several advantages in having LP people or teams being
> the branch owners and maintainers. We can extract those details and
> inject them into the charm bundle when the store is exporting the
> charm.
> 

+1, lp identities would be very convienent, i assume we'll need them anyways to 
publish to the store via lp.

Distinct but related there's also a need imo for some category tags/trove 
classifiers in metadata.yaml for presenting a category ui for a charm store.

https://bugs.launchpad.net/juju/+bug/890453

cheers,
Kapil