18:00:01 <felixfontein> #startmeeting Ansible Community Meeting
18:00:01 <zodbot> Meeting started Wed May  5 18:00:01 2021 UTC.
18:00:01 <zodbot> This meeting is logged and archived in a public location.
18:00:01 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:01 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:01 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:01 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:00:05 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:09 <abadger1999> Greetings!
18:00:11 <cybette> o/
18:00:12 <samccann> o/
18:00:12 <andersson007_> o/
18:00:13 <jillr> o/
18:00:17 <felixfontein> #chair abadger1999 cybette samccann andersson007_ jillr
18:00:17 <zodbot> Current chairs: abadger1999 andersson007_ cybette felixfontein jillr samccann
18:00:27 <felixfontein> welcome everyone :)
18:00:29 <felixfontein> #topic Updates
18:00:53 <felixfontein> #info Ansible-4.0.0beta2 has been released on 5/5/2021: https://groups.google.com/g/ansible-devel/c/NLQrgEiEEMw
18:00:56 <felixfontein> #info Ansible-4.0.0rc1 is scheduled for 5/11/2021
18:00:56 <tadeboro> o/
18:00:58 * dericcrago waves
18:00:59 <felixfontein> #info Ansible-4.0.0 final is scheduled for 5/18/2021
18:01:02 <felixfontein> #chair tadeboro dericcrago
18:01:02 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago felixfontein jillr samccann tadeboro
18:01:09 <dmsimard> /o\
18:01:17 <felixfontein> #chair dmsimard
18:01:17 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein jillr samccann tadeboro
18:01:21 <cybette> #info
18:01:36 <cybette> oops
18:01:52 <felixfontein> I'm wondering whether that shows up in the minutes :)
18:02:21 <cybette> #info Register for Ansible Contributor Summit 2021.06 https://www.eventbrite.com/e/ansible-contributor-summit-202106-registration-152686374055?aff=irc
18:02:25 <cybette> I guess we'll find out :P
18:02:37 <felixfontein> yep :)
18:02:55 * gundalow waves
18:02:56 <cybette> not sure if undo will remove the previous command instead
18:03:25 <cybette> #info Add topics to Contributor Summit 2021.06 agenda https://hackmd.io/@ansible-community/contrib-summit-202106
18:03:26 <felixfontein> #chair gundalow
18:03:26 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:03:51 <abadger1999> Heh, I'm not sure :-)
18:06:32 <felixfontein> ok, let's start with a discussion ;)
18:06:35 <felixfontein> #topic Including disk_info in community.general, or: how much duplicated functionality do we want to make life easier for users?
18:06:38 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/11
18:07:07 <felixfontein> we already discussed this two weeks ago (the issue is kind of a summary of that discussion)
18:07:29 <felixfontein> #info PR in question: https://github.com/ansible-collections/community.general/pull/2213
18:07:30 <github-linkbot> https://github.com/ansible-collections/community.general/pull/2213 | open, created 2021-04-09T08:41:12Z by saranyasridharan: Module to get disk information [affects_2.10,has_issue,integration,module,needs_revision,new_contributor,new_module,new_plugin,plugins,system,tests,unit]
18:07:45 <aminvakil> o/
18:07:59 <felixfontein> #chair aminvakil
18:07:59 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:08:57 <aminvakil> my only concern with this module is if it's going to bring confusion to new users searching for a module to get their disks info (should they use this module or setup module)
18:09:30 <abadger1999> I think they should use this module if they can't figure out how to get the information from setup.
18:10:09 <felixfontein> we could also provide a filter(s) which make it easier to extract information; I've created a WIP PR: https://github.com/ansible-collections/community.general/pull/2323
18:10:10 <github-linkbot> https://github.com/ansible-collections/community.general/pull/2323 | open, created 2021-04-21T19:40:46Z by felixfontein: [WIP] Add groupby_as_dict filter [WIP,affects_2.10,integration,needs_triage,new_plugin,plugins,tests]
18:10:29 <felixfontein> that allows to map a list of dicts to a dict of dicts, indexed by one attribute of the dicts
18:11:07 <felixfontein> then it's basically `ansible_facts.ansible_mounts | community.general.groupby_as_dict('device')` to get the same result as from the new module
18:11:25 <aminvakil> iirc this filter couldn't be in setup module documentation as discussed? (because it's in c.g)
18:11:46 <abadger1999> <nod> Do we want to see how the original submitter feels about the new filter?
18:12:08 <felixfontein> I'm not sure whether it belongs in setup's docs anyway, since that module returns **a lot** of facts and it cannot document every possible use of every fact it returns
18:12:10 <jillr> I like felixfontein's filter, it's much more general purpose
18:12:25 <felixfontein> (of course we can also have the filter *and* the new module)
18:12:30 <tadeboro> That filter scares me because it is really general.
18:12:40 <jillr> and docs  :)  all the things!
18:13:21 <felixfontein> tadeboro: for me, that would be an advantage and not a disadvantage :)
18:13:39 <samccann> heh
18:13:43 <jillr> tadeboro: would docs help?  like, specific cases for when you want to use it and also ways it could go wrong / when not to use it?
18:13:56 <dmsimard> if it's general maybe it's a good fit for community.general ¯\_ (ツ)_/¯
18:14:07 <felixfontein> dmsimard: lol :)
18:14:12 <abadger1999> Yeah, I am leaning towards "have both" but I'd love to hear what the original submitter thought.  If they think that the filter is sufficient then that would be fine with me.
18:14:14 <tadeboro> Well, from my experience, once I gave users very flexible things, they started programming in YAML. And expected me to support then ...
18:14:27 <tadeboro> *them
18:14:29 <samccann> So when I look at the disk_info PR (examples in the module docs) - I find it very easy to understand.  When I look at the proposed ways to do with with setup and filters, my eyes glaze over.  I would rate myself as an ansible newbie, not the average ansible user
18:15:08 <tadeboro> If I had to choose between general filter and this new dedicated module, I would go with the module.
18:15:24 <dmsimard> tadeboro: I agree though not mutually exclusive
18:15:24 <andersson007_> if i were a user, i'd prefer what is easier to use with less movement. Especially if i were a user with a lot of other tasks to do
18:15:28 <cybette> cyb-clock chimes: 15 minutes into meeting, 9 minutes on "Including disk_info in community.general"
18:16:10 <felixfontein> tadeboro: but then you'll be stuck the next time you need to extract data the same way... should we add new modules for every case where someone wants to extract something specific by a key from a list that another module returns?
18:17:13 <tadeboro> Collections we maintain are scenario-based because we learned such things are easier for our users to use. So we actually do add new things for new scenarios if needed.
18:17:39 <felixfontein> my main hesitation against adding that module is that I want to prevent that we start merging new modules which basically do subsets of what other modules do just because it's a little bit easier to use... in the end I guess we can have 50 modules for some little things that setup also delivers, though not as easily usable
18:18:10 <aminvakil> felixfontein: +1
18:18:15 <samccann> there seems to be other disk_info like modules that this would provide symmetry with, fwiw.
18:18:22 <jillr> but is the use case here "getting disk info is hard" or "getting data from a list of dicts is hard, and this user happens to need it for disk info this time"
18:18:38 <samccann> so question - win_disk_info - was that a necessary module because setup couldn't do whatever that one does?
18:18:48 <abadger1999> Although, I would vote to include, I'm also okay if community.general doesn't want to duplicate functionality as long as the ansible package can include duplicates.
18:18:49 <tadeboro> Well, I am not a fan of info modules in general. They are nice for integration tests, but using them in the playbook seems wrong to me most of the time.
18:18:58 <felixfontein> I think it would be better to instead document how to extract such information given existing modules and existing/new filters. once we have a mechanism to include docs in the docsite from collections, we could even add this from c.g's side (instead of having it in ansible/ansible's docs)
18:19:44 <felixfontein> samccann: I don't know win_disk_info... but considering it exists it probably would be nice if disk_info is similar to it
18:20:47 <felixfontein> #info related module: https://docs.ansible.com/ansible/latest/collections/community/windows/win_disk_facts_module.html
18:21:02 <felixfontein> interestingly, that module returns a *list* of dicts
18:21:10 <felixfontein> from its examples:
18:21:11 <felixfontein> # Get first system disk disk: '{{ ansible_facts.disks|selectattr("system_disk")|first }}'
18:21:36 <tadeboro> "All info modules that can return one-or-more things should return lists" <- one of our rules.
18:22:32 <felixfontein> so to use win_disk_facts, you would need a filter like community.general.groupby_as_dict
18:22:40 <jillr> I'd guess win_disk_facts is because there isnt a powershell setup so it actually returns facts
18:23:30 <felixfontein> jillr: also you can't say "only return info on disk <x>", which would not really make it a _facts module
18:24:13 <felixfontein> so basically win_disk_facts returns something similar to what setup returns, while the new disk_info returns something else that according to what tadeboro quoted is not something an info module should return
18:25:01 * dmsimard needs to dad ops momentarily, brb
18:25:02 <felixfontein> tadeboro: where did you find that sentence?
18:25:37 <tadeboro> Our rules is Steampunk team rules, not community rules. I was not specific enough, sorry.
18:25:52 <tadeboro> Steampunk - the team I work with on collections.
18:26:06 <felixfontein> ah sorry, I understood `our` as `ansible community` :)
18:26:31 <felixfontein> I tried grepping for it in ansible's docsite :)
18:27:14 <felixfontein> ok. should we vote?
18:27:48 <abadger1999> Sure.  Since this one was close last time, please include whether you're on the steering committee or not when you vote.
18:27:56 <jillr> I have nothing else to add, let's vote
18:28:03 <felixfontein> hmm, or vote about including that filter first? the vote on that module might depend on the result for that
18:28:33 <jillr> yeah that makes sense
18:28:55 <felixfontein> VOTE: should we add generic filters like community.general.groupby_as_dict (https://github.com/ansible-collections/community.general/pull/2323)?
18:28:56 <github-linkbot> https://github.com/ansible-collections/community.general/pull/2323)? | open, created 2021-04-21T19:40:46Z by felixfontein: [WIP] Add groupby_as_dict filter [WIP,affects_2.10,integration,needs_triage,new_plugin,plugins,tests]
18:29:06 <jillr> SC: +1
18:29:07 <felixfontein> (of course that does not mean that this should be merged without further review :) )
18:29:14 <andersson007_> SC:+1
18:29:21 <tadeboro> +1
18:29:22 <bcoca> felixfontein:  teh _facts vs _info was host  properties vs external to host, think you are confusing that now
18:29:26 <felixfontein> what's `SC:` ?
18:29:29 <abadger1999> +1
18:29:31 <aminvakil> +1 (non-SC)
18:29:35 <andersson007_> steering commettee
18:29:37 <samccann> (cargo) +1
18:29:37 <felixfontein> ah
18:29:39 <felixfontein> :)
18:29:43 <felixfontein> +1
18:29:45 <cybette> +1 (non SC)
18:30:15 <felixfontein> bcoca: facts that depend on which option was passed to the module to retrieve them don't really count as facts in my POV
18:30:31 <andersson007_> (tadeboro: stepped down?)
18:30:40 <bcoca> then no module provides facts, even setup, by that definition
18:30:46 <cybette> cyb-clock chimes: 30 minutes into meeting, 24 minutes on "Including disk_info in community.general"
18:31:01 <tadeboro> DC: +1 (not yet, just multitasking at the moment ;)
18:31:03 <felixfontein> andersson007_: no, it's just not necessary to state that :) we usually don't care, except if it is tight, then we count, but then we know who's on the SC and who's not :)
18:31:06 <tadeboro> s/dc/sc/
18:31:07 <andersson007_> :)
18:31:30 * dmsimard is back
18:31:34 <felixfontein> just wanted to ask "what's DC? yet another acronym?" :D
18:31:58 <dmsimard> I'll +0 this one but I was wondering, by way of this vote, are we implicitly resolving the discussion around whether or not we should allow net new content in c.g/c.n at all ?
18:32:04 <jillr> this is my fault for not wanting to type out "steering commitee"  :)
18:32:30 <gundalow> +0 (SC) - I've not used filters that much, so don't have an end-user perspective
18:32:36 <felixfontein> bcoca: afaik you can say which facts setup should retrieve, but not adjust the value of some facts by parameters to setup?
18:32:41 <jillr> dmsimard: sort of?  since we're voting to include a new filter?
18:33:03 <dmsimard> jillr: I don't mind, but it's been a topic that we've kicked down the road for a long time now :)
18:33:24 <felixfontein> dmsimard: that also crossed my mind... but I guess right now we allow contributions, so until we decide we don't allow them anymore, it's more like asking 'which things do we think are ok generally?'
18:33:37 <tadeboro> We might resolve the new content issue per-partes ;)
18:33:48 <abadger1999> Heh, I was thinking the same thing (but I'm +1 to new content in c.g too ;-)
18:33:49 <jillr> dmsimard: the bar should probably be high, but this at least seems to be a clear need the community has
18:34:55 <andersson007_> yeah, we accept a lot of stuff from vendors. It would be unfair to close the only door for regular independent folks
18:34:58 <felixfontein> so far we have 5x+1, 1x0 from SC and 3x+1, 1x0 otherwise
18:35:23 <felixfontein> #chair
18:35:23 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:35:49 <felixfontein> (if I didn't miscount)
18:36:10 <abadger1999> I think that's enough to definitely pass it.
18:36:36 <felixfontein> #agreed we should add generic filters like community.general.groupby_as_dict (https://github.com/ansible-collections/community.general/pull/2323)
18:36:45 <tadeboro> I got the same numbers when counting.
18:37:14 <felixfontein> VOTE: should we add new modules like disk_info that simplify usage of results from setup, but which can also be replaced by setup result + one filter?
18:37:21 <bcoca> felixfontein: at that point they are not info either, but 'computation'
18:37:25 <abadger1999> +1 (SC)
18:37:26 <felixfontein> (I formulated it a bit more general, I hope that's ok for everyone)
18:37:26 <andersson007_> SC: +1
18:37:44 <andersson007_> bcoca: lol
18:37:45 <felixfontein> 0 (SC)
18:37:51 <aminvakil> -1 (non-SC)
18:37:55 <samccann> +1 (baggage)
18:38:04 <tadeboro> SC +1
18:38:07 * andersson007_ don't forget that dmsimard is not SC
18:38:22 <dmsimard> yeah I'm just tagging along for the ride
18:38:27 <andersson007_> :)
18:38:28 <cybette> 0 (non SC)
18:38:34 <felixfontein> bcoca: depends, in this case it allows you to filter the contents of a fact. it's basically _fact + simple filter combined in one module. for that's still _info
18:38:39 <dmsimard> +0 (not SC)
18:38:54 <jillr> SC: +0 generally (+1 if the specific case has real differentiation from a more general filter)
18:38:57 <bcoca> felixfontein:  which i would reject, keep filter as filter
18:39:09 <gundalow> -1 (SC) Add to existing docs
18:39:22 <felixfontein> bcoca: you can also vote here :) (you'll be counted under non-SC)
18:39:53 <bcoca> i abstain to avoid having to maintain .. if i voted i would feel required to maintain also
18:40:19 <bcoca> and i barely have the time to maintain what i currently do ...
18:40:23 <felixfontein> bcoca: you only have to maintain if you vote +1 :P
18:40:29 <bcoca> s/barely/dont at all/
18:41:04 <samccann> heh
18:41:05 <felixfontein> current tally: SC: 3x+1, 2x0, 1x-1; non-SC: 1x+1, 2x0, 1x-1
18:42:09 <jillr> should we vote to review them on a case-by-case basis instead of having a general policy to add?
18:42:47 <felixfontein> I think that's what this implies, we don't generally accept them, but also don't generally deny them, the vote is in the middle :)
18:43:31 <felixfontein> #info Vote on "should we add new modules like disk_info that simplify usage of results from setup, but which can also be replaced by setup result + one filter?" resulted in 3x+1, 2x0, 1x-1; non-SC: 1x+1, 2x0, 1x-1, no clear result
18:43:39 <felixfontein> VOTE: should we include disk_info in community.general?
18:43:48 <tadeboro> So I guess we should ask the PR author now if the existing stuff + new filter is enough?
18:44:00 <jillr> tadeboro: +1
18:44:10 <felixfontein> yes, we can do that, and if they don't think it is enough, vote again next week
18:44:17 <felixfontein> (or whenever we have time)
18:44:34 <felixfontein> does that sound good for everyone?
18:44:40 <abadger1999> The two things that we can do are what tadeboro asks and get the remaining steering committee members to give us hteir votes in the issue or at the next meeting.
18:44:56 <felixfontein> or do both :)
18:44:56 <andersson007_> +1
18:44:57 <jillr> felixfontein: agreed
18:45:17 <abadger1999> yeah, I meant we should do both but didn't phrase it well.
18:45:24 <tadeboro> +1 to sleep things over.
18:45:40 <felixfontein> I'll put votes (with names) in the issue, so people can add their votes if they have an opinion
18:45:47 <abadger1999> Cool :-)
18:45:55 <felixfontein> #action felixfontein update issue #11
18:46:00 <felixfontein> #undo
18:46:00 <zodbot> Removing item from minutes: ACTION by felixfontein at 18:45:55 : felixfontein update issue #11
18:46:08 <felixfontein> #action felixfontein update issue ansible-community/community-topics#11
18:46:14 <cybette> cyb-clock chimes: 45 minutes into meeting, 39 minutes on "Including disk_info in community.general"
18:46:20 <felixfontein> #topic Collection requirements and checklist: add clarifications about info / facts modules
18:46:23 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/14
18:46:26 <felixfontein> #info PR: https://github.com/ansible-collections/overview/pull/169
18:46:27 <github-linkbot> https://github.com/ansible-collections/overview/pull/169 | open, created 2021-04-29T07:40:14Z by Andersson007: Add _info / _facts module related notes
18:47:39 <felixfontein> this basically expands some of the information from ansible's dev guide to the collection requirements document
18:47:47 <felixfontein> based on the inclusion discussion from last week
18:48:21 <samccann> adding some copyedit nits while y'all discuss
18:48:26 <jillr> I know we don't want to reproduce the dev guide here, but I think we should be a bit clearer about _info vs _facts, /me thinks of wording...
18:48:43 <tadeboro> I think highlighting the important stuff from existing docs is really helpful. So +1 on the content (grammar is not my forte, so ...)
18:49:45 <jillr> suggestion in the PR
18:50:57 <felixfontein> jillr: I'd probably even say "modules that return ansible_facts are named <something>_facts (and do not return non-facts)"
18:51:22 <jillr> felixfontein: I'm on board with that
18:51:54 <andersson007_> (please tell me when you finish reviewing, then we could merge proposals based on thumbs ups and merge the PR)
18:52:15 <abadger1999> jillr: I think we may be working towards reproducing hte dev guide here.  gundalow, do you want to speak on that?
18:52:36 <samccann> andersson007_ done reviewing
18:52:56 <andersson007_> i think i see conflicts:)
18:53:38 <jillr> abadger1999: I don't disagree, but this feels like one of those things that is a recurrent source of confusion  ¯\_(ツ)_/¯
18:53:51 <gundalow> abadger1999: into ansible-guidelines (aka checklist?)
18:54:13 <jillr> are we spending more time in inclusion reviews pointing out parts of the dev guide than it takes to turn the whole dev guide into a checklist?
18:54:16 <andersson007_> jillr: please put a period in the last suggestion:)
18:54:19 <abadger1999> Yeah, the new document/site that you're working on
18:54:21 <jillr> andersson007_: ah thanks!
18:54:21 <gundalow> For the moment, feel free to add stuff into ansible-core's dev_guides. That will (overtime) get moved to the right places
18:54:42 <felixfontein> jillr: I removed the 'only' from your suggestion, because otherwise the addition at the end doesn't say anything new :)
18:55:08 <gundalow> jillr: My hope is that we will add a lot more details (the WHY) to the inclusion criteria
18:55:52 <gundalow> I think a lot of the dev_guide checklists (in ansible-core) will get moved into the ansible-guidelines repo
18:56:21 <felixfontein> I added some :+1:s
18:56:53 <andersson007_> ok, i'll commit all having them
18:56:55 <samccann> there's an ansible-guidelines repo??
18:57:21 <bcoca> ^ what sam said
18:57:45 <gundalow> samccann: not yet. We will move inclusion criteria out of ansible-collections/overview to ansible/ansible-guidelines
18:57:54 <gundalow> (to be created)
19:00:04 <cybette> cyb-clock chimes: 1 HOUR into meeting, 14 mins on "Collection requirements and checklist"
19:00:05 <andersson007_> done
19:00:34 <andersson007_> should we vote or just merge?
19:00:57 <felixfontein> should we quickly vote on the result?
19:01:01 <felixfontein> VOTE: should we merge https://github.com/ansible-collections/overview/pull/169 ?
19:01:09 <jillr> +1
19:01:15 <samccann> +1
19:01:22 <felixfontein> +1
19:01:23 <aminvakil> +1 (non-SC)
19:01:39 <tadeboro> +1
19:01:47 <andersson007_> +1 CS
19:01:51 <abadger1999> +1
19:01:54 <cybette> +1 (non SC)
19:02:20 <gundalow> +1 SC
19:03:04 <felixfontein> #agreed merge https://github.com/ansible-collections/overview/pull/169
19:03:15 <felixfontein> do you want another topic (Deprecate community.general's nios modules/plugins), or should we stop for today?
19:03:45 <andersson007_> I'll merge then, thanks everyone!
19:03:47 <abadger1999> I'd vote +1 on that but I don't know if anyone wants to discuss before voting ;-)
19:03:59 <felixfontein> thanks andersson007_!
19:04:04 <felixfontein> #topic Deprecate community.general's nios modules/plugins
19:04:04 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/13
19:04:20 <felixfontein> the background is that we decided last week to not include infoblox.nios_modules in Ansible (yet)
19:04:38 <felixfontein> most of the content from infoblox.nios_modules is currently also in community.general
19:04:47 <felixfontein> I'd like to get rid of it :)
19:05:10 <felixfontein> I think it's also better for users if everything is in one place
19:05:11 <tadeboro> +1 for deprecation.
19:05:16 <aminvakil> it will cause more confusion for users too
19:05:27 <aminvakil> +1 for deprecation
19:05:32 <jillr> +1 deprecate
19:05:35 <felixfontein> aminvakil: the deprecation message would say where they can find the 'real' content
19:05:43 <abadger1999> +1
19:06:09 <felixfontein> should we vote directly? (people already seem to do so :D )
19:06:19 <andersson007_> let's vote
19:06:36 <felixfontein> VOTE: should we deprecate the nios modules/plugins in community.general (for removal in c.g 5.0.0)?
19:06:46 <dmsimard> +1
19:06:48 <jillr> +1
19:06:48 <andersson007_> +1 SC
19:06:49 <aminvakil> +1
19:06:59 <felixfontein> (if infoblox.nios_modules gets included in time, we can replace the deprecation with redirects, assuming the modules/plugins are compatible)
19:07:02 <felixfontein> +1 SC
19:07:07 <samccann> +1 (trunk)
19:07:20 <cybette> +1 (non SC)
19:07:39 <tadeboro> +1
19:07:46 <felixfontein> #chair
19:07:46 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:08:10 <gundalow> +1 SC
19:08:45 <felixfontein> #agreed we deprecate the nios modules/plugins in community.general (for removal in c.g 5.0.0)
19:08:53 <felixfontein> #topic open floor
19:09:14 <felixfontein> #info please take a look at https://github.com/ansible-community/community-topics/issues/15 (Should we have a collection linter?)
19:09:21 <felixfontein> I guess we'll discuss that next week
19:11:04 <felixfontein> does anyone has something for the open floor?
19:12:53 <gundalow> Nothing from me
19:12:58 <felixfontein> speak up now, or shut up until next week :)
19:13:08 <andersson007_> heh
19:13:21 <andersson007_> this is your last chance:)
19:13:30 <felixfontein> as always, you can create issues in https://github.com/ansible-community/community-topics/issues if you want something discussed
19:13:43 <felixfontein> #endmeeting