Toshio and I have started on this a little while ago, but haven't gotten it fully integrated yet.
https://github.com/sivel/ansible-testing One problem is all of the current modules that don't yet pass. On Monday, October 5, 2015, Greg DeKoenigsberg <[email protected]> wrote: > On Mon, Oct 5, 2015 at 7:09 AM, <[email protected] <javascript:;>> > wrote: > > FWIW it would be nice to have some tool which could check the module > > guidelines automatically. > > Less manual work and less room for disagreement. > > You are so, so right about this. :) > > --g > > > > > Just my two cents, > > Dennis Benzinger > > > > > > On Friday, September 25, 2015 at 5:09:45 PM UTC+2, Greg DeKoenigsberg > wrote: > >> > >> The backlog of New Modules in Extras is here: > >> > >> https://github.com/ansible/ansible-modules-extras/labels/new_plugin > >> > >> The original intention of the Extras module split was to allow us to > >> be more generous with acceptance criteria of new modules, to help grow > >> our functionality and community more quickly. I don't think we're > >> making as much progress as we could be making in merging these > >> modules, and I believe it's because our current process is too > >> restrictive. > >> > >> Here are the baseline criteria for acceptance of modules into Extras, > >> as I see them: > >> > >> 1. New modules have been tested in good faith by users who care about > >> them; > >> 2. New modules adhere to the module guidelines; > >> 3. The submitter of the module is willing and able to maintain the > >> module over time. > >> > >> What do these three criteria have in common? Trust. > >> > >> We must trust that the people who say "I have tested this module" have > >> actually done so. We trust that people who say "this module passes > >> guidelines" have checked against those guidelines carefully. We trust > >> that the submitters of these modules will fix issues as they arise, > >> and evaluate and merge pull requests as needed. > >> > >> So that's what I'd like to do. No longer will we require approvals of > >> a small set of individuals; instead, we'll open up the review process > >> to everybody. Here's how it will work: > >> > >> * All new modules will require two approvals: > >> + One "worksforme" approval from someone who has > >> thoroughly tested the module, including all parameters > >> and switches; > >> + One "passes_guidelines" approval from someone who > >> has vetted the code according to the module guidelines. > >> > >> * Either of which can be given, in a comment, by anybody > >> (except the submitter, of course). > >> > >> * Any module that has both of these, and no "needs_revision" > >> votes (which can also be given by anybody) will be approved > >> for inclusion. > >> > >> * The core team will continue to be the point of escalation for > >> any issues that may arise (duplicate modules, disagreements > >> over guidelines, etc.) > >> > >> Does this new policy increase the risk of poor reviews, thus > >> increasing the risk of buggy modules? It might. But I think that's > >> okay. Modules are modular for a reason; if a module doesn't work > >> perfectly, the pain is limited only to the flawed module itself -- > >> which is not the end of the world. So long as we have maintainers who > >> are committed to improving their modules over time, I think we'll be > >> fine. > >> > >> Note that inclusion of a module in Extras does not imply permanence in > >> the same way that inclusion in Core does. If modules in Extras go > >> unmaintained, we will seek new maintainers, and if we don't find new > >> maintainers, we will ultimately deprecate them. > >> > >> Our new policy is effective immediately, and we will start going > >> through the backlog of new modules asap. If there's a module you've > >> been waiting to see, you can start testing and reviewing them right > >> away, adding the text "passes_guidelines" or "worksforme" or > >> "needs_revision" as appropriate. > >> > >> Module guidelines can be found here: > >> > >> > http://docs.ansible.com/ansible/developing_modules.html#module-checklist > >> > >> Thanks, as always, for your support and your patience. > >> > >> --g > >> > >> -- > >> Greg DeKoenigsberg > >> Ansible Community Guy > >> > >> Find out why SD Times named Ansible > >> their #1 Company to Watch in 2015: > >> http://sdtimes.com/companies-watch-2015/ > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ansible Project" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected] <javascript:;>. > > To post to this group, send email to [email protected] > <javascript:;>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/ansible-project/1479b6f7-3ef4-4d4a-8428-b72ee424cbff%40googlegroups.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Greg DeKoenigsberg > Ansible Community Guy > > Find out why SD Times named Ansible > their #1 Company to Watch in 2015: > http://sdtimes.com/companies-watch-2015/ > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:;>. > For more options, visit https://groups.google.com/d/optout. > -- Matt Martz @sivel sivel.net -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAD8N0v92XrEXd9%2BxfaW7i%2B%2Bj7tUygNCeyAu0UWundE-JanGvbA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
