Charm maintainership in metadata.yaml?
kapil.thangavelu at canonical.com
Tue Nov 15 00:52:03 UTC 2011
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
+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.
More information about the Juju