That is correct. As of now there are 17 failing modules in extras with a total of 19 errors:
https://gist.github.com/sivel/53489d707a010bf8fad3 I'll look into getting it integrated in extras soon, which may necessitate a couple of changes to provide an exclusion list at run time. On Mon, Oct 5, 2015 at 11:10 AM, Greg DeKoenigsberg <[email protected]> wrote: > On Mon, Oct 5, 2015 at 11:12 AM, Matt Martz <[email protected]> wrote: > > 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 > > Shiny. :) > > > One problem is all of the current modules that don't yet pass. > > I presume you're saying this is a problem in the context of > integrating into Travis. We could mitigate that by setting up an > exclude list containing all modules that don't currently pass, with > the intention of whittling down that list over time. > > I love the idea of using this as a starting point. > > --g > > > > > On Monday, October 5, 2015, Greg DeKoenigsberg <[email protected]> wrote: > >> > >> On Mon, Oct 5, 2015 at 7:09 AM, <[email protected]> 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]. > >> > 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/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]. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > > > -- > > Matt Martz > > @sivel > > sivel.net > > > > > > -- > 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/ > -- 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/CAD8N0v8iHhgyX5A7Dwb5SxgJ%2B9gBq%3DqpaubY6Ap0sX6zZ8ucvw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
