19:00:37 <felixfontein> #startmeeting Ansible Community Meeting
19:00:37 <zodbot> Meeting started Wed Mar 24 19:00:37 2021 UTC.
19:00:37 <zodbot> This meeting is logged and archived in a public location.
19:00:37 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:37 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:38 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
19:00:38 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping!
19:00:46 <felixfontein> #chair jillr dmsimard cybette
19:00:46 <zodbot> Current chairs: cybette dmsimard felixfontein jillr
19:00:47 <andersson007_> o/
19:00:47 <tadeboro> o/
19:00:47 <cybette> o/
19:00:52 <felixfontein> #chair andersson007_ tadeboro
19:00:52 <zodbot> Current chairs: andersson007_ cybette dmsimard felixfontein jillr tadeboro
19:00:55 * dericcrago waves
19:00:56 <abadger1999> Bom dia
19:01:01 <felixfontein> #chair dericcrago abadger1999
19:01:01 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein jillr tadeboro
19:01:04 <dmsimard> \o
19:01:05 * samccann waves
19:01:06 * apple4ever waves
19:01:12 <felixfontein> #chair samccann apple4ever
19:01:12 <zodbot> Current chairs: abadger1999 andersson007_ apple4ever cybette dericcrago dmsimard felixfontein jillr samccann tadeboro
19:01:20 <felixfontein> #topic Updates
19:02:01 <felixfontein> #info ansible-core 2.11.0b3 has been released (whose argspec validation code was refactored, so check your collection whether it still works!)
19:02:34 <felixfontein> #info Ansible 4.0.0a2 has been released (including that new beta version of ansible-core)
19:02:54 <felixfontein> any other news? I'm sure there are :)
19:03:27 <dmsimard> #info #ansible-digitalocean is now a thing, feel free to join if you're using DO or would like to contribute
19:03:56 * gundalow waves
19:04:26 <cybette> #chair gundalow
19:04:26 <zodbot> Current chairs: abadger1999 andersson007_ apple4ever cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:05:20 <felixfontein> dmsimard: just found yet another topic: Apache 2.0 license in new collections (hpe.nimble uses it)
19:05:45 * dmsimard gasp
19:06:04 <dmsimard> no other updates from me
19:06:10 <felixfontein> if there are no more updates, let's begin with Python version requirements :)
19:06:19 <cybette> one more...
19:06:22 <cybette> (sorry finding link)
19:06:35 <felixfontein> np, I'll wait
19:06:37 <cybette> #info Please help determine the date of next Ansible Contributor Summit by voting here https://www.surveymonkey.co.uk/r/RBMJFXS
19:06:44 <cybette> ok that's all, thanks :)
19:06:49 <felixfontein> :)
19:06:53 <felixfontein> #topic Python version requirements: https://github.com/ansible-collections/overview/pull/151
19:06:53 <github-linkbot> https://github.com/ansible-collections/overview/pull/151 | open, created 2021-01-25T12:48:11Z by Ompragash: New Policy Regarding Python Compatibility for Collections
19:07:05 <felixfontein> ompragash updated the PR with the latest proposal
19:07:29 <felixfontein> I think it's good, though I have a few tiny suggestions (mostly stylistic)
19:07:34 <felixfontein> did anyone else take a look at the proposal?
19:07:39 <felixfontein> (if not, now is the time... :) )
19:08:19 <samccann> reading thru it but mostly for copyedit nits
19:08:35 * jillr reading the diff
19:09:09 <tadeboro> I did read it and have nothing to add.
19:09:16 <felixfontein> let's try to finally get it merged :)
19:09:19 <dmsimard> in the middle of reading it
19:09:21 <felixfontein> (so this discussion is finally done... :) )
19:10:14 <jillr> yeah other than a couple copy edit nits (which I don't want or need to vote on :) ) +1
19:10:27 <dmsimard> I think it could use some wordsmithing the essence of the policy makes sense to me
19:10:38 <dmsimard> s/the/but the/
19:11:06 <felixfontein> please add suggestions for wordsmithing / copy-editing, then we can discuss / merge them
19:13:11 <dmsimard> yep, will do.
19:13:16 <samccann> one comment for the hive mind - ansible-core I think is strongly suggesting python 3.8 and will require it 'at some point soonish'. Do we need a similar note in this doc somewhere?
19:13:57 <felixfontein> samccann: it will only require it for ansible-core 2.12, which will be in Ansible 5.0.0, so we can update this once that comes closer
19:14:05 <dmsimard> I'm pretty sure I've seen a patch (for 2.12 or devel?) that adds a check for python>=3.8 controller-side
19:14:23 <felixfontein> dmsimard: devel already warns if Python < 3.8 is used on controller-side
19:14:29 <abadger1999> Added all of my comments
19:14:31 <dmsimard> right, that's what I meant
19:15:15 <cybette> cybette-clock says: 15 min into the meeting!
19:15:32 <dmsimard> before I forget, another item for the agenda: potential re-scheduling of the meeting with daylight savings changes
19:15:45 <felixfontein> good point
19:16:04 <felixfontein> ok, is anyone still adding suggestions?
19:16:08 <acozine> dangit, brain fail
19:16:12 <jillr> github is being difficult and slow, I'm happy to defer to other folk's minor suggestions
19:16:13 <acozine> time changes are terrible
19:16:32 <felixfontein> #chair acozine
19:16:32 <zodbot> Current chairs: abadger1999 acozine andersson007_ apple4ever cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:16:59 <dmsimard> I'm not sure about "other environment" but I can't come up with a better suggestion :)
19:17:22 <felixfontein> dmsimard: since nobody suggested a better change for some weeks now, let's keep it :)
19:18:18 <dmsimard> yeah, I don't bikeshed for the sake of it :D
19:18:32 <felixfontein> ok, let's go through the changes (top to bottom):
19:18:33 <felixfontein> 1. https://github.com/ansible-collections/overview/pull/151#discussion_r600685213
19:19:14 <felixfontein> (that last part shouldn't really be a list entry, and samccann also improved the wording)
19:19:24 <felixfontein> (I just converted a double space to a single space)
19:19:34 <samccann> nearly done with my nit review
19:19:51 <felixfontein> is that change fine for everyone?
19:20:00 <abadger1999> Should the checklist entry contain more info or say "read the Python Compatibility section if you support less" ?
19:20:01 <jillr> should we all go through and thumbs up/down each diff?
19:20:13 <jillr> then we can discuss anything without consensus?
19:20:31 <abadger1999> jillr: That sounds sensible.
19:20:37 <acozine> change is good by me
19:20:43 <felixfontein> jillr: sounds like a good idea!
19:20:48 <samccann> ok finished my nits
19:22:20 <samccann> as for other-environment, the only thing that comes to mind as an alternative is `noncontroller environment`  ...which isn't necessarily better
19:23:49 <acozine> heh
19:23:54 <dmsimard> yeah, ¯\_(ツ)_/¯
19:24:04 <dmsimard> thanks for wordsmithing :)
19:24:11 <felixfontein> ok, is everyone through?
19:24:24 <andersson007_> done with the thumbs ups?
19:24:28 <acozine> yep, all suggested changes 👍
19:24:32 <dmsimard> yeah I don't see any objections
19:24:49 <samccann> LGTM
19:24:50 <abadger1999> I see all thumbs up(s)
19:24:52 <felixfontein> I see 5-7 thumbs up right now
19:24:54 <jillr> lgtm
19:24:57 <felixfontein> (depending on item)
19:25:02 <abadger1999> Does anyone have a thought about my question on the checklist?
19:25:23 <felixfontein> even 8 :)
19:25:44 <tadeboro> abadger1999: Question? I did not see any.
19:25:56 <jillr> yeah I also missed the question
19:25:56 <abadger1999> <@abadger1999> Should the checklist entry contain more info or say "read the Python Compatibility section if you support less" ?
19:26:00 <jillr> ah
19:26:11 <felixfontein> ah
19:26:20 <abadger1999> I don't demand it since I think the full guideline is authoritative and the checklist is a quick summary.
19:26:38 <abadger1999> But the present wording of the checklist might be misleading if someone does not read the full guideline
19:26:43 <jillr> I think it's heplful to link to the specific place for more info on that though, +1
19:27:04 <felixfontein> yep, or add a bit more wording
19:27:13 <felixfontein> should I merge all suggestions with 7+ votes?
19:27:36 <acozine> how many chairs do we have today?
19:27:44 <felixfontein> #chair
19:27:44 <zodbot> Current chairs: abadger1999 acozine andersson007_ apple4ever cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:27:50 <felixfontein> 12
19:28:03 <felixfontein> though not all seem to have voted
19:28:12 <felixfontein> and there's no downvote anywhere
19:28:14 <acozine> so 7 is 50%+1 . . . do we have any "nay" votes?
19:28:16 <acozine> merge it
19:28:23 <tadeboro> Merge it.
19:28:37 <dmsimard> well, not as is
19:28:41 <acozine> heh
19:28:43 <dmsimard> gotta commit the suggestions first
19:28:45 <jillr> commmit and ship
19:29:10 <acozine> what @jillr said
19:29:19 <samccann> yep agreed
19:29:23 <tadeboro> My merge was referencing felixfontein "merge all suugestions with +7 ..."
19:29:57 <felixfontein> ok, there's one suggestion left: https://github.com/ansible-collections/overview/pull/151/files#r600685666
19:30:00 <felixfontein> (6 votes)
19:30:23 <felixfontein> I'm not 100% happy with it (it's my own) since this section is explicitly about module utils - but parts of that section also apply to plugin utils
19:31:00 <cybette> cybette-clock says we're 24 min on topic "Python version requirements" and 30 min in meeting
19:31:19 <tadeboro> I +1 that because that info does not seem to hurt anyone.
19:31:27 <acozine> I guess we could call the section `Standards and conventions for developing shared utilities in a collection`
19:31:30 <acozine> then it would fit
19:31:37 <abadger1999> (I added my suggestion for the checklist wording.  But I can also put that up for a followup PR if people wnat)
19:31:58 <acozine> module utils and plugin utils are all shared utils
19:32:16 <acozine> but I think it's fine as is, too
19:32:23 <abadger1999> We could change the heading if it bothers us that the section only lists module_utils right now.
19:32:35 <felixfontein> I added a suggestion for the heading
19:32:58 <felixfontein> what acozine said above: module -> shared
19:33:16 <abadger1999> should we s/utilities/code/ as well?
19:33:25 <abadger1999> or say `module and plugin utilities`
19:33:41 <felixfontein> `module and plugin` sounds good to me
19:33:54 <samccann> is this still the  title? cuz it's getting kinda long
19:33:59 <felixfontein> 'shared code' could also be something else that is importable (i.e. basically everything)
19:35:30 <abadger1999> ` Standards for developing module and plugin utilities`
19:35:32 <acozine> I like 'shared utilities' because it gives a hint if the reader doesn't already know what module_utils or plugin_utils are
19:35:51 <felixfontein> VOTE: a) shared code, b) shared utilities, c) module and plugin utilities, d) 'Standards for developing module and plugin utilities'
19:36:00 <abadger1999> `Standards for developing shared code in a collection`
19:36:07 <jillr> sorry I got pulled into a bunch of internal pings, I'm ok with shared utils so long as that term is defined somewhere
19:36:28 <samccann> If we get rid of 'conventions' in that old title, that helps a bit with the overall length
19:36:39 <felixfontein> the next line (first bullet point) mentions both module_utils and plugin_utils (with the suggestion)
19:36:57 <samccann> b (shared utilities)
19:37:02 <acozine> samccann: I like that idea
19:37:20 <acozine> oh, and abadger1999  mentioned the same idea
19:37:25 <felixfontein> 'Standards for developing module and plugin utilities in a collection'?
19:37:36 <abadger1999> <nod> Following on from acozine liking "shared" insteead of "modules and plugins".  If we use shared, I like code instead of utilities because a reader might not already know what a utility is in this context
19:38:27 <samccann> so is shared code only possible in shared utilities?
19:38:35 <acozine> I'm also thinking of translations, where `module_utils` will likely be rendered in English but `shared code` will be translated
19:39:15 <felixfontein> samccann: that's the only things that should be shared, but in practice plugins can import whatever they want
19:39:26 <acozine> samccann: from within a collection, I believe shared code is only possible in utilities
19:39:36 <felixfontein> (they can also import other plugins, modules, things from completely different directories, even from unit tests...)
19:39:41 <acozine> yeah, plugins can import all kinds of things
19:39:47 <abadger1999> samccann: hand wavy.... but also hand wavy about whether we'd want this section to apply to anything that's shared. (My gut says yes but there's not a lot of examples of what it could be yet)
19:39:56 <acozine> but these standards can't control those other things
19:40:13 <felixfontein> abadger1999: in that case every .py file in a collection would count as shared code :)
19:40:30 <felixfontein> and the _ prefix convention doesn't work well for plugins or modules
19:40:36 <andersson007_> "shared code (for example, ...)"?
19:40:36 <abadger1999> Other parts of the requirement do limit what would be considered shared code, I suppose.
19:40:37 <samccann> so in general, the  title should match what we are trying to control.  My preference so far is to keep utilities there
19:41:03 <samccann> we need a cyb-clock update cuz I feel like we might be bikeshedding at this point.
19:41:33 <acozine> if we use the full words, not the directory title, I'm good with ^^^
19:41:43 <felixfontein> VOTE: a) shared code vs. b) shared utilities vs. c) module and plugin utilities
19:41:49 <acozine> so back to abadger1999's suggestion of `Standards for developing module and plugin utilities`
19:42:00 <samccann> c and this ^^
19:42:02 <acozine> c)
19:42:11 <felixfontein> c)
19:42:25 <abadger1999> c)
19:42:25 <jillr> c (I'm ok with b though)
19:42:34 <andersson007_> с)
19:42:40 <felixfontein> VOTE: Standards for developing module and plugin utilities
19:42:41 <tadeboro> c)
19:42:43 <dmsimard> c is fine with me
19:42:48 <tadeboro> +1
19:42:48 <felixfontein> +1
19:43:23 <cybette> c
19:43:35 <felixfontein> more +1/-1 for the concrete title 'Standards for developing module and plugin utilities'?
19:43:46 <acozine> +1
19:43:47 <jillr> +1
19:43:48 <cybette> +1
19:43:50 <andersson007_> +1
19:44:01 <samccann> +1
19:44:03 <dmsimard> +1
19:44:22 <felixfontein> ok, great, I've adjusted the suggestion :)
19:44:24 <abadger1999> +1
19:44:48 <felixfontein> should we vote on merging the remaining three suggestions in a batch? or does someone wants to discuss the checklist change by abadger1999 separately?
19:45:10 <cybette> cybette-clock says we're 39 min on topic "Python version requirements" and 45 min in meeting
19:45:17 <tadeboro> I am fine with batching them together.
19:45:34 <samccann> batch and merge so we can hit whatever the next agenda item is
19:45:49 <abadger1999> +1 from me for batching and +1 to the batch :-)
19:45:52 <acozine> +1 to batch and merge
19:45:56 <andersson007_> +1
19:45:59 <felixfontein> VOTE: should we merge the three suggestions, and then merge the PR?
19:46:03 <tadeboro> +1
19:46:04 <andersson007_> +1
19:46:04 <felixfontein> +1
19:46:08 <jillr> +1
19:46:35 <cybette> +1
19:46:53 <felixfontein> (there will be a quick follow-up PR / commit to include the link to the Python version section in the checklist)
19:46:54 <dmsimard> +1
19:46:55 <samccann> +1
19:47:25 <felixfontein> #agreed https://github.com/ansible-collections/overview/pull/151 should be merged with the remaining last three suggestions
19:47:28 <felixfontein> thanks everyone!
19:47:44 <felixfontein> #topic Change CI of stable-1 branches of community.network and community.general from devel to stable-2.11 once stable-2.11 exists?
19:47:47 <felixfontein> #info https://github.com/ansible/community/issues/539#issuecomment-804661401
19:47:50 <felixfontein> #info This means: no longer testing with devel, only with stable-2.{9,10,11}
19:47:53 <felixfontein> the next topic will hopefully be quick ;)
19:48:12 <felixfontein> next monday ansible-core 2.11.0rc1 will be released and stable-2.11 will be created
19:48:30 <felixfontein> at which point collections need to update their CI config to also test against stable-2.11 (next to stable-2.10, optionally stable-2.9 and devel)
19:48:52 <bcoca> i would say you need those 2
19:49:11 <bcoca> 2.9 as its 'long term pre colleciotn distro' and only one officially suported
19:49:12 <felixfontein> for community.general and community.network - which currently have two stable branches and the main branch - this will increase CI load, so my suggestion would be to convert devel in the oldest stable branch (stable-1) to stable-2.11 and no longer test them against devel
19:49:25 <bcoca> devel as otherwise you might mask issues until its too late
19:49:44 <felixfontein> bcoca: main and stable-2 will be tested against both devel and stable-2.11 (and stable-2.10 and stable-2.9)
19:49:58 <felixfontein> in these two concrete collections
19:50:20 <dmsimard> right we're talking about older stable branches
19:50:23 <acozine> felixfontein: with a greater CI load, what behaviors do we see? longer wait times for PRs? greater maintenance overhead?
19:50:23 <felixfontein> for other collections it depends on whether they support Ansible 2.9 at all (some don't), and whether they want to test against devel (they should, but not all want to)
19:50:49 <felixfontein> acozine: mainly RH pays more money. usually nobody has to wait for stable-1 backports (except dericcrago and me).
19:52:02 <abadger1999> It makes sense to me that older stable branches would be tested on less
19:52:04 <acozine> so the oldest stable branch would stop testing against `devel`? this seems reasonable
19:52:10 <felixfontein> acozine: yes
19:52:14 <tadeboro> In collections I help with, we test against stable branches on each push/merge/whatever, and devel stuff is tested twice a week. But we only have one stable branch, so this is not directly comparable.
19:52:27 <acozine> eventually well stop releasing that collection version, right?
19:52:30 <dmsimard> felixfontein: I have no objections
19:52:32 <acozine> so we might as well taper it off
19:52:34 <felixfontein> tadeboro: c.g's stable-1 currently has ~150 CI runs
19:52:40 <felixfontein> I don't want to increase that number :)
19:53:05 <felixfontein> stable-2 and main have less CI runs since a lot test-intensive content was moved out for 2.0.0
19:53:25 <acozine> aahhhhhh, `stable-1` is the branch for c.g 1.x . . . I'd been reading that as `stable minus 1` and `stable minus 2`
19:53:43 <dericcrago> acozine - I did the same thing for awhile
19:53:46 * acozine reorganizes her worldview
19:53:55 <felixfontein> acozine: ah :) yeah, sorry, that wasn't clear. stable-1 is the branch for 1.x.y, similar to stable-2.10 being the branch for 2.10.x versions in ansible/ansible :)
19:54:34 <samccann> so is stable-1 still actually supported since Ansible 2.10 is EOL?
19:54:52 <felixfontein> samccann: kind of
19:54:59 <acozine> maybe as an add-on for Ansible 2.9?
19:55:08 <felixfontein> samccann: bugfixes that can easily be backported are still backported
19:55:23 <felixfontein> (thanks to webknjaz's bot :) )
19:55:32 <acozine> because the Ansible community is very helpful and supportive
19:55:58 <felixfontein> and there are still 1.3.x releases from time to time (when there are security fixes, or incompatibilities with ansible-core 2.11 betas for eaxmple)
19:56:17 <dmsimard> FWIW there is a LTS topic about maintaining (or not) past releases (such as 2.10, 3.x soon) https://hackmd.io/plQlGzcFRFGLnPXIeg3cwQ
19:56:42 <samccann> cool thanks. sorry to crowd the current conversation about switching off devel.
19:56:44 <andersson007_> it promises to be too long for today
19:56:50 <felixfontein> VOTE: is this change for c.g and c.n ok, i.e. can stable-1 stop testing against devel once stable-2.11 is there?
19:56:56 <tadeboro> +1
19:56:59 <samccann> +1
19:57:00 <felixfontein> +1
19:57:01 <dmsimard> We're kind of out of time for the topic today but would like folks to chime in about some of those pros and cons of doing it (I'll add that it costs us more money that was mentioned earlier :p)
19:57:04 <jillr> +1
19:57:08 <andersson007_> +1
19:57:08 <dmsimard> +1
19:57:14 <cybette> +1
19:57:15 <acozine> +1
19:58:08 <andersson007_> dmsimard: isn't it worth creating a dedicated issue maybe?
19:58:08 <felixfontein> #agreed c.g and c.n stable-1 branch switches devel to stable-2.11 in CI on Monday instead of adding stable-2.11 next to devel
19:58:11 <felixfontein> thanks!
19:58:18 <felixfontein> ok, one last quick topic:
19:58:18 <felixfontein> #topic Potential re-scheduling of the meeting with daylight savings changes
19:58:35 <dmsimard> andersson007_: maybe, I wanted to have some discussion around it but an issue works too
19:58:41 <felixfontein> since both US and Europe are in summer time at next week's meeting, we could adjust times again if we want to
19:59:05 <gundalow> +1 to moving earlier
19:59:17 <felixfontein> for andersson007_ tadeboro and me the meeting will be at 21:00 with the current time, for gundalow it will be 20:00 I think
19:59:18 <dmsimard> Should we have a poll (doodle comes to mind) and people vote on what time works best for them ?
19:59:24 <samccann> +1
19:59:25 <acozine> earlier is fine for me
19:59:26 <andersson007_> + 1 to moving earlier
19:59:30 <cybette> +1 for earlier
19:59:33 <samccann> oh +1 to moving earler
19:59:33 <felixfontein> so moving it earlier will essentially restore the state from two (?) weeks ago for most people here :)
19:59:44 <acozine> I could go several hours earlier if we want to get radical
19:59:50 <samccann> heh
19:59:54 <dmsimard> Would you consider moving earlier than that ? I always feel bad for our EMEA/APAC friends
20:00:01 <tadeboro> +0 (my days are already a mess, soooo ... ;)
20:00:06 <gundalow> tadeboro: lol
20:00:09 <acozine> heh
20:00:13 <gundalow> abadger1999: how early do you want to go?
20:00:16 <felixfontein> for me it's one hour earlier, or better three hours earlier :)
20:00:23 <andersson007_> +1 to felixfontein
20:00:25 <felixfontein> (i.e. same as docs meeting)
20:00:25 <andersson007_> :)
20:00:50 <acozine> that would have the advantage of being predictable - same time, two days in a row
20:01:00 <cybette> cyb-clock says we're 1 HOUR into the meeting
20:01:08 <acozine> is it too hard on abadger1999 and anyone else on west-coast time, though?
20:01:27 <dmsimard> what is the proposed time ? 15:00 UTC ?
20:01:34 <felixfontein> we can also schedule next week's meeting one hour earlier (and the other ones after that), and still decide to move it even earlier next week
20:01:41 <acozine> true
20:01:56 <felixfontein> 18:00 UTC (one hour earlier than now) or 15:00 UTC (like docs meeting)
20:01:57 <jillr> I dont do DST ever anyway so I just assume things will move (maybe) or not (maybe), I'm good with the entire 3 hour block surrounding this UTC time
20:02:19 <jillr> so, earlier, later, same, whatever works for me
20:02:23 <acozine> jillr are you now on Mountain Time or Pacific Time?
20:02:33 <felixfontein> ok, since we're basically out of time, how about moving to 18:00 UTC tentatively, and discuss this a bit more next week?
20:02:33 <abadger1999> I'd like to be no earlier than 8:00 local time
20:02:34 <jillr> MST (not MDT) or UTC-7
20:02:38 <dmsimard> 3PM UTC is 8:00AM on west coast
20:02:50 <acozine> felixfontein: +1
20:02:51 <jillr> wait wut - 1500 UTC is too early
20:02:54 <felixfontein> I'll create an issue where people can add their opinions on these options (or make other suggestions)
20:03:15 <jillr> (not that I don't have 2-3 meetings at that time most weeks already)
20:03:19 <jillr> (on this same day)
20:03:20 <felixfontein> I'm fine with sticking to 18:00 UTC
20:03:30 <cybette> +1 for 18:00 UTC
20:03:36 <dmsimard> let's try 18:00 UTC for the next one and re-discuss if need be
20:03:40 <felixfontein> VOTE: move meeting to 18:00 UTC (and potentially discuss another time later)
20:03:44 <acozine> +1
20:03:46 <jillr> +1
20:03:47 <felixfontein> +1
20:03:47 <andersson007_> +1
20:03:48 <dmsimard> +1
20:03:49 <abadger1999> +1
20:03:52 <tadeboro> +0
20:04:07 <acozine> heh, tadeboro disappears into a timeless void
20:04:13 <felixfontein> if someone wants another time, please create an issue for discussion and link to it in the agenda :)
20:04:28 <cybette> +1
20:04:55 <felixfontein> #agreed the community meeting will be at 18:00 UTC from now on
20:05:00 <felixfontein> #topic Open Floor
20:05:12 <felixfontein> #info please read https://hackmd.io/plQlGzcFRFGLnPXIeg3cwQ on LTS for Ansible
20:05:26 <dmsimard> ^ yes, and do comment/add things you think
20:05:31 <felixfontein> abadger1999: do you know whether someone asked RH legal about licenses for collections?
20:05:49 <felixfontein> the requirements say "We will have a list of other open source licenses which are allowed as soon as we get Red Hat's legal team to approve such a list for us."
20:05:52 <abadger1999> I've asked but got no reply yet
20:06:29 <felixfontein> because we have a first collection application which is using Apache 2.0 for everything (modules, docs frgament, module utils)
20:06:37 <abadger1999> I'm pretty sure red hat legal will approve other licenses for modules since this send to be  a mere aggregation
20:07:02 <abadger1999> (plugins would have to be gplv3+ since they run in the controller process)
20:07:14 <abadger1999> *this seems to be
20:07:31 <felixfontein> abadger1999: how about docs fragments?
20:08:01 <felixfontein> I guess they are loaded as plugins though
20:08:21 <felixfontein> if anyone wants to know, the collection in question is hpe.nimble (https://github.com/ansible-collections/ansible-inclusion/discussions/13)
20:08:42 <abadger1999> I think doc_fragments will be okay.  The other thing is for things in the controller, they'll need to be gplv3 compatible, not necessarily gplv3 and apache is compatible with gplv3
20:09:14 <felixfontein> doc_fragments might be properly imported (as plugins) by ansible-doc
20:09:48 <felixfontein> (as opposed to modules AFAIK)
20:10:13 <tadeboro> Is nible certified? If yes, then I guess someone already looked into this issue, right?
20:10:24 <felixfontein> bcoca: do you know? ^^
20:10:43 <abadger1999> Doc_fragments are somewhat grey because they're loaded by the controller.  But they might be considered data (just like the documentation strings pulled from the modules by ansible-doc). I will get clarification from legal, though, because you're right, they are imported to get access to the documentation
20:11:41 <felixfontein> abadger1999: thanks for checking!
20:12:03 <felixfontein> since nobody brought up more topics for open floor, let's close
20:12:04 <bcoca> while they are techincally code, i consider them data/documentation, since they have no real logic in them
20:12:04 <felixfontein> #endmeeting