Proposal for new charm policies.

[Clint Byrum]

Excerpts from Marco Ceppi's message of 2013-05-09 16:57:11 -0700:
> On Thu, May 9, 2013 at 1:51 PM, Jorge O. Castro <jorge at ubuntu.com> wrote:
> 
> > Specifically I'd like to propose these 5 things to move into policy:
> >
> > - 3 acks for charm reviews before a charm is considered "reviewed" in the
> > store.
> >
> > Now that we're getting more mature we need to keep the charm quality
> > high. So along with landing charm testing we'd like to start doing
> > more peer review on incoming charms.
> >
> >
> This concerns me given the number of reviewing charmers currently and the
> size of our queue on any one basis. Currently charms are just ACK'd by one
> charmer and that can create review backups. Moving to three people will
> potentially create quite a large entry for reviews to occur. I completely
> agree that gating on reviews landing with more eyes on is a great way to
> help curb our growing quality concern. What I'd like to do, if this were to
> land as policy, would be to find a way to both motivate current charmers
> and find a way to more or less consider charm-contributors as "Jr Charmers"
> and have them providing reviews then we might have enough man power to keep
> the queue quieter. I'd love to talk about these and other suggestions
> during UDS.

Whats missing here is automated testing chiming in on merge
proposals. Having seen the way the OpenStack CI infrastructure helps
submitters avoid obvious mistakes, it makes the reviewers' job much
more enjoyable. You're no longer going over things with a fine toothed
comb, but instead reading something that appears to work.

That said, 3 is way too many. 2 reviewers should be enough with automated
testing gating things.