Charm Store policy updates and refinement for 2.0

[Charles Butler]

Big +1 to the categories

What i'd like to see is the policy document move to strong language where
we can build tooling around the automated checking of policy.

Refactoring the MUSTS and SHOULDS give us a strong lead on that language.
MUST == has to be satisfied
SHOULD = area for improvement - (proper use of warn, which wont fail charm
proof for a change)

eg: We require OSI approved licenses, we can scan the copyright file for
that with a license bot to find the lingo of approved licenses, otherwise
it flags for human review. It may be an acceptable license we're not aware
of.

The more points in policy we can convert to strongly typed lingo, the more
targeted and automated we can make portions of policy review, and also
scopes the mission of ~charmers. A limited resource who is responsible for
enforcing this document.



On Fri, Mar 18, 2016 at 11:59 AM Jorge O. Castro <jorge at ubuntu.com> wrote:

> Hello everyone,
>
> With 2.0 around the corner we decided to spend some time cleaning up
> the page everyone loves to hate, the Juju Charm Store policy:
>
> https://jujucharms.com/docs/1.25/authors-charm-policy
>
> and here is what I would like to propose:
>
> https://github.com/castrojo/docs/blob/master/src/en/authors-charm-policy.md
>
> I've done a few things here:
>
> - I've separated it from one huge paragraph to sections, General,
> Testing and Quality requirements, Metadata requirements, and Security
> requirements.
> - I've split out things that a charm/bundle MUST do and what it SHOULD
> do in each section to make it clearer on what is a hard requirement
> and what is a recommendation.
> - I've removed most of the Ubuntu-specific jargon and generalized it
> to include other OSes such as CentOS.
> - Made documenting interfaces and external dependencies a requirement.
>
> There are also some new policies that we need ack from ~charmers in
> order to implement. Specifically we've made the testing and quality
> requirements explicit. I've also added a requirement of using Juju
> Resources (which appears to be undocumented?) for payloads.
>
> Recommendations from everyone on what we should include here would be
> most welcome, specifically our recommendations around Windows charms
> is non-existent.
>
>
> --
> Jorge Castro
> Canonical Ltd.
> http://jujucharms.com/ - The fastest way to model your service
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160318/56e15498/attachment.html>