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/ -- 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/CAM1FbhEVW40h4%3DKtFgtZS87uN%2BVpaoQRP2LrZK_LQ_e73pkvWA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
