charm teams

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of 2013-03-13 12:12:20 -0700:
> On Wed, Mar 13, 2013 at 3:59 PM, Mark Ramm
> <mark.ramm-christensen at canonical.com> wrote:
> > I think a long queue is hugely detrimental. It causes loss of momentum for
> > contributors, allows work-in-progress to pile up, and causes all kinds of
> > related inefficiencies.
> 
> Hugely agreed.
> 
> > And beyond that centralization of the review process is not going to scale
> > as far as we need it too either.
> >
> > What would happen if a central group of people were required to review
> > *every* package in debian?
> >
> > I think it is smart to do something that allows for us to decrease turn
> > around time -- and think hard about other ways of improving quality and
> > facilitate increased cross-pollination.  Two things which come to mind is
> > better documentation and  more attention to "gold standard" practices, and
> > more resources behind automated testing.
> 
> I'd be even more aggressive: any charm that has a single "graduated"
> maintainer doesn't need to be reviewed. Packages with more interested
> parties can preserve the reviewing procedure, and they will hopefully
> have a reduced turnaround time because the parties should be actually
> interested on the project and charm, rather than being just a
> firewall.
> 
> Someone being "graduated" is purely a matter of peer-reviewing. When
> other graduated maintainers are happy with the given person's
> contributions, and believe that the conventions and level of quality
> will be respected.
> 
> It's better to have an actively maintained charm with less quality,
> than a "golden" charm that nobody touches because reviewing kills all
> the motivation.

We always intended for non ~charmers to be able to own charms. As long
as ~charmers can also be added to a group so that they can affect change,
this should be something that is quite simple to achieve.

And on reviews, agreed, the owners of a charm set the review tone. If
one person is actively maintaining a charm and has demonstrated skills
enough to work alone, then they should be the judge of whether or not
they want somebody to review changes.

This is basically like Debian's DMUpload flag, where non-DD's can maintain
a package without any sponsor blocking their progress.

Its worth noting here that Debian has a much stronger web of trust than
~charmers has. The policy right now is two +1's from active ~charmers.
I think it would make sense to have those +1's be conditional on knowing
for sure who a person is, given that we're giving them root on any of
the charm users' systems.