18:00:04 <felixfontein> #startmeeting Ansible Community Meeting
18:00:04 <zodbot> Meeting started Wed Jan  5 18:00:04 2022 UTC.
18:00:04 <zodbot> This meeting is logged and archived in a public location.
18:00:04 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:04 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:05 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:05 <felixfontein> 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:08 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:11 <briantist> o/
18:00:20 <felixfontein> #chair briantist
18:00:20 <zodbot> Current chairs: briantist felixfontein
18:00:22 <andersson007_> o/
18:00:25 <felixfontein> #chair andersson007_
18:00:25 <zodbot> Current chairs: andersson007_ briantist felixfontein
18:00:27 <tadeboro> o/
18:00:28 * gundalow waves
18:00:28 <acozine> o/
18:00:32 <felixfontein> #chair tadeboro gundalow acozine
18:00:32 <zodbot> Current chairs: acozine andersson007_ briantist felixfontein gundalow tadeboro
18:00:50 <felixfontein> #topic Updates
18:00:57 <felixfontein> #info Happy New Year 2022 :)
18:01:12 <andersson007_> 🎉
18:02:35 <gundalow> #info We are excited to announce that briantist has joined the Ansible Steering Committee. Brian has been a very active community member for several years. He has contributed to the project as a developer, reviewer, collection maintainer, documentation contributor, he helped other contributors and users on IRC / Matrix and GitHub as well as the steering committee to make right decisions.
18:02:48 <felixfontein> \o/
18:02:49 <gundalow> congratulations briantist
18:02:56 <felixfontein> congratulations briantist!
18:02:56 <andersson007_> congratulations!
18:02:58 <samccann> o/
18:03:03 <briantist> thank you! 😊
18:03:11 <felixfontein> #chair samccann
18:03:11 <zodbot> Current chairs: acozine andersson007_ briantist felixfontein gundalow samccann tadeboro
18:03:15 <samccann> congrats!
18:03:23 <dericcrago> congratulations briantist !
18:03:40 <felixfontein> #chair dericcrago
18:03:40 <zodbot> Current chairs: acozine andersson007_ briantist dericcrago felixfontein gundalow samccann tadeboro
18:03:46 <bcoca> congrats+condolences
18:03:58 <felixfontein> #chair bcoca
18:03:58 <zodbot> Current chairs: acozine andersson007_ bcoca briantist dericcrago felixfontein gundalow samccann tadeboro
18:04:28 <briantist> lol bcoca
18:04:29 <felixfontein> bcoca: we're not *that* mean ;)
18:04:56 <andersson007_> :)
18:05:55 <felixfontein> #info thanks to briantist, PRs in the community.docker repo now have a docs build and docs diff
18:06:59 <briantist> ^ that is available for any other collections who want to try it out as well
18:07:02 <gundalow> #info We had 24 issues of The Bullhorn, the Ansible Community newsletter, last year. Subscribe via https://us19.campaign-archive.com/home/?u=56d874e027110e35dea0e03c1&id=d6635f5420
18:07:52 <andersson007_> I'll take a look at the PR, thanks!
18:07:58 <felixfontein> wow, that's quite a lot!
18:09:02 <felixfontein> #topic Active voting topics
18:09:02 <felixfontein> Since we want to be more asyncronous, please don't forget about the following async votes!
18:09:24 <felixfontein> Since today the topics which contain open votes have a new label, `active-vote`
18:09:41 <felixfontein> #info https://github.com/ansible-community/community-topics/issues?q=is%3Aissue+is%3Aopen+label%3Aactive-vote will show all active votes
18:09:53 <andersson007_> i've just put a summary in https://github.com/ansible-community/community-topics/issues/51#issuecomment-1005953413
18:09:58 <felixfontein> Currently the following votes are open:
18:09:58 <felixfontein> Repository instead of Changes impacting collection contributors & maintainers Issue: https://github.com/ansible-community/community-topics/issues/51
18:10:01 <felixfontein> community.general and community.network: reduce maintenance for old stable branches: https://github.com/ansible-community/community-topics/issues/55
18:10:04 <felixfontein> Should documentation use FQCN for ansible.builtin modules or just the short name: https://github.com/ansible-community/community-topics/issues/58
18:10:45 <felixfontein> there are also some issues which are waiting for opinions (they aren't formal votes), like https://github.com/ansible-community/community-topics/issues/57 and https://github.com/ansible-community/community-topics/issues/59
18:11:32 <andersson007_> acozine: zbr you have a chance to vote too https://github.com/ansible-community/community-topics/issues/51#issuecomment-989600473
18:11:32 <felixfontein> (it probably makes sense to have a special label for things that are actively collecting opinions but aren't formal votes yet)
18:12:27 <felixfontein> I hope that once everyone's back from vacation/holidays/..., that the community topics repo gets more active dicsussions :)
18:13:29 <acozine> andersson007_: I'll put a note on the issue - since most folks are in favor of a GitHub repo as the mechanism for distributing those types of changes, a separate repo seems like a good idea
18:13:42 <samccann> felixfontein: what do we consider the correct label for semantic markup issue - https://github.com/ansible-community/community-topics/issues/53 ?
18:13:53 <andersson007_> acozine: thanks!
18:14:01 <tadeboro> I have a plan to do some triage over the weekend in the topics repo. I know some issues should be closed, others would probably benefit if we set some kind of dealine on them, ...
18:14:03 <samccann> I know it's waiting on internal people, but are we done with evangelizing this for community votes?
18:14:36 <felixfontein> samccann: that's a good question... it's a discussion, so discussion_topic is already a good one. maybe also a new 'opinions wanted' label. though this applies to almost all topics, I guess
18:14:55 <felixfontein> tadeboro: good idea!
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:25 <samccann> ok how about...
18:15:29 <felixfontein> maybe we can also have a 'featured topic per week' (or several ones), in the hope that it attracts more attention
18:15:38 <samccann> #info opinions wanted on semantic markup proposal - https://github.com/ansible-community/community-topics/issues/53
18:15:56 <samccann> So it's in the notes etc. Not sure how else we capture the attention of collection owners?
18:16:33 <samccann> did we ever put it out in the bullhorn? I think this week's edition is smallish so it might get more eyeballs? (that and any other one we want people looking at?)
18:16:40 * bcoca does not recommend showing up at their door late at night and knocking obsessively
18:16:51 <felixfontein> samccann: I don't remember, but that definitely would be a good idea
18:16:57 <andersson007_> maybe posting this in the changes impacting issue?
18:17:23 <andersson007_> while it exists:)
18:17:31 <tadeboro> samccann: That is a hard thing to do. I learned before holidays that even maintainers of collections included in the ansible package do not know we have documents with requirements ...
18:17:33 <felixfontein> andersson007_: maybe we already did, but it's hard to search in there :)
18:17:40 <andersson007_> felixfontein: heh
18:18:20 <felixfontein> tadeboro: not really surprises me... we created issues with that in every repo, but I guess some people simply ignore issues in their repos... or maybe only onboarded later on and never were told by existing maintainers
18:19:38 <samccann> so I don't specifically see a 'community topics' section in the bullhorn. I can add this to help wanted, but maybe we need something that highlights things we want people to participate in?
18:19:53 <samccann> or maybe it exists as a label/heading already and I'm not looking in the right spot (bullhorn)
18:21:54 <gundalow> I think a `proposals` section in The Bullhorn could be good. Can use it for other projects as well
18:22:31 <andersson007_> another question is how to finish the topics that we voted on asynchronously, like https://github.com/ansible-community/community-topics/issues/51#issuecomment-1005953413. I think after Alicia adds the comment, we could do it but how / who? Chairperson maybe? I don't know
18:22:59 <samccann> ok I'll open an issue here to request a `proposal` section - https://github.com/ansible-community/ansible.im/issues
18:24:13 <tadeboro> andersson007_: I think anyone on the steering committee should be able to count the things up and write a summary. But maybe it would best if we say that at least two people need to count things in order to reduce the changes of mistakes being made.
18:24:39 <andersson007_> tadeboro: yep, sounds good
18:25:09 <tadeboro> andersson007_: And if we set due dates on issues, it should also be clear when we can start doing final counts and/or nagging people that have yet to vote.
18:25:09 <andersson007_> tadeboro: so there are at least two summary comments
18:25:38 <andersson007_> tadeboro: also sound good:)
18:25:40 <felixfontein> andersson007_: in https://github.com/ansible-community/community-topics/issues/51#issuecomment-989600473 you wrote the vote is open until next monday, so I guess it should stay open until then :)
18:25:55 <andersson007_> felixfontein: really? Ok:)
18:26:15 <acozine> some folks might still be on holiday
18:26:36 <felixfontein> the other two active voting issues also have due dates
18:27:07 <felixfontein> acozine: it has been open since mid December, if someone is on vacation for a month they will miss it, but everyone else should have had a chance to vote :)
18:27:36 <acozine> felixfontein: very true
18:27:36 <andersson007_> should we put due dates in the descriptions like [voting ends 10.01.22] or something
18:27:43 <dericcrago> speaking of voting, what's the "correct" way? adding an expressive comment or adding a reaction to the original post? the latter would automatically tally 🤷
18:27:47 <andersson007_> to make it more noticeable
18:28:01 <felixfontein> dericcrago: reactions are not so good since you cannot track their history
18:28:14 <felixfontein> andersson007_: that's probably a good idea
18:29:04 <gundalow> "voting ends at $DATE" is covered by Gwmngilfn's proposal
18:29:23 <tadeboro> I would preffer if we vote in comments. And the way one should vote should probably be part of the original proposal (+/-, selecting one of multiple options, selecting subset of things, etc.)
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:05 <felixfontein> tadeboro: I agree
18:30:06 <andersson007_> a possible option is always creating something like https://github.com/ansible-community/community-topics/issues/51#issuecomment-989600473
18:30:44 <dericcrago> tadeboro: that's a good point about there being multiple options, I was only thinking +1 / -1
18:32:34 <felixfontein> ok, I'd like to switch topics to something else that needs both awareness and clever ideas to fix (if there are any - I'm not sure it is possible though)
18:32:47 <briantist> I prefer we do keep options as simple as possible, so +1/-1, unless necessary
18:32:49 <felixfontein> (if you want to keep discussing this topic, please say so :) )
18:32:50 <andersson007_> if there are no volunteer, I could put [voting ends at $DATE] in the descriptions tomorrow
18:33:13 <briantist> (that's all I had to say, fine to switch topics for me)
18:33:55 <felixfontein> #topic distutils LooseVersion etc. replacement
18:34:00 <felixfontein> Since distutils is deprecated (since Python 3.10) and will be removed from Python 3.12's standard library, it should be removed
18:34:03 <felixfontein> One thing in it that's used a lot is LooseVersion (and its friends StrictVersion etc.)
18:34:06 <felixfontein> I had a PR for removing it (that was replicated into quite a few collections):
18:34:09 <felixfontein> #info Original PR: https://github.com/ansible-collections/community.general/pull/3936
18:34:10 <github-linkbot> https://github.com/ansible-collections/community.general/pull/3936 | closed, created 2021-12-22T22:03:13Z by felixfontein: Prepare for distutils.version being removed in Python 3.12 [bug,module,has_issue,filter,inventory,module_utils,database,plugins,cloud,files,gitlab,monitoring,net_tools,os,packaging,source_control,system,notification,identity,web_infrastructure,backport-3,backport-4] 
18:34:12 <felixfontein> Unfortunately it had some unintended consequences:
18:34:13 <felixfontein> With Ansible 2.9 before 2.9.20, and ansible-base 2.10 before 2.10.8, Ansible cannot handle the module_utils.version package added, since it contains a try/except statement around an import of an ansible-core 2.12 module_utils
18:34:17 <felixfontein> #info Unintended consequences (bug report): https://github.com/ansible-collections/community.docker/issues/267
18:34:20 <felixfontein> Which means that for these Ansible 2.9/ansible-base 2.10 versions, the modules using this won't work.
18:34:32 <felixfontein> I *think* there is no way to fix this in a good way for these versions, without breaking it for later versions
18:34:51 <felixfontein> If there is not, it's probably best to document it, like this:
18:34:52 <felixfontein> #info Changelog PR: https://github.com/ansible-collections/community.general/pull/3979
18:35:23 <felixfontein> does anyone have an idea how to fix this in another way? (or has comments on the changelog fragment formulation? :) )
18:35:51 <briantist> should that PR include an update to `requires_ansible:` in `runtime.yml`?
18:36:07 <felixfontein> briantist: no, since most modules/plugins still work fine with older versions
18:36:16 <briantist> ah right good call
18:36:20 <felixfontein> (this might be different for other collections though)
18:36:37 <tadeboro> Ugh, that issue is nasty.
18:36:47 <felixfontein> tadeboro: indeed!
18:38:41 <samccann> what are the rules around this sort of partial breakage? Is this considered a breaking change for the collection (and thus would not be part of Ansible until Ansible 6?) or is it allowed in Ansible 5?
18:39:01 <felixfontein> I'm also wondering whether it is a good idea to backport this change to older versions, since it is a breaking change. on the other hand, users can upgrade their Ansible 2.9 / ansible-base 2.10 to a version which works
18:39:15 <felixfontein> samccann: that's a very good question :)
18:39:30 <felixfontein> samccann: actually for Ansible 5/6 it does make no difference, since they are based on ansible-core, not on ansible-base or Ansible 2.9
18:39:36 <felixfontein> (and there it just works fine)
18:40:04 <felixfontein> it only affects old versions of ansible-base 2.10 and Ansible 2.9, and there are newer versions of both 2.9 and 2.10 which do not have this problem
18:41:10 <samccann> So the updated collection is 'breaking change' in the sense that users with older 2.9/2.10 will ..break.
18:41:34 <samccann> But we don't have an individual 'changelog' per collection, do we?
18:41:53 <samccann> or I should say does that impacted collection include a changelog of its own?
18:41:54 <felixfontein> samccann: yes. though one could also say that it's Ansible 2.9 and ansible-base 2.10 which have a bug, so it's not the collection's fault
18:42:05 <felixfontein> samccann: collections usually have their own changelog as well
18:42:58 <samccann> thinking out loud, I'd add a 'porting guide' or upgrade section to the collection readme to say you must also upgrade 2.9/2.10 etc
18:43:11 <felixfontein> I think that I will remove the backport in c.general's stable-3 and c.crypto's stable-1 branch (for c.docker's stable-1 branch it's already released, no idea whether it's a good idea to still revert it)
18:43:14 <tadeboro> Hmm, if collection metadata states that ansible <= 2.9.13 is supported, then I would say failing is a breaking change.
18:43:17 <samccann> which might be what your PR is doing... haven't looked yet
18:43:53 <samccann> tadeboro: when are you allowed to update collection metadata?
18:44:13 <samccann> as in what collection version? major, minor, dot?
18:44:18 <felixfontein> tadeboro: that's something I'm afraid of, since that means that these collection versions will not work with Python 3.12 just to make users of these ancient versions happy :)
18:44:57 <tadeboro> samccann: In all honesty, I did not think about this much, but my gut tells me that when I bump major version.
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:55 <briantist> I think I am missing something really obvious about why this is a bad idea... but would reversing the try/catch to try `distutils.version` first solve this?
18:46:42 <felixfontein> briantist: I think it will only work if the module_utils that's only in ansible-core 2.12 is not imported in any try or except block
18:47:04 <tadeboro> briantist: If I understand things correctly, ansible packaging facilities will fail no matter what order we do.
18:47:29 <felixfontein> the only way to fix this for Python 3.12 is that every collection has its own vendored copy of LooseVersion
18:47:44 <briantist> I see.. ok
18:47:52 <felixfontein> which is ... ugly. very ugly :)
18:48:24 <briantist> is it THAT ugly? many collections are dropping 2.9/2.10 support in a few months anyway right, and then the vendored version could be removed?
18:48:40 <tadeboro> For collections I maintain, I would probably just wait until 2.9 and 2.10 die and the problem goes away ;)
18:48:49 <felixfontein> it's still ugly, but yes, that's possible
18:49:45 <felixfontein> probably vendoring is best right now...
18:49:45 <tadeboro> For certified stuff, I would probably vendor the file, but those things tend to get ugly anyway (once you start talking to telkos, things quickly get very very old ;)
18:50:16 <felixfontein> tadeboro: or just use Ubuntu 20.04, then you get Ansible 2.9.6 ;-)
18:50:30 <briantist> and we could vendor the one that's in ansible core, rather than the distutils one right? which.. well I thought would be somewhat less ugly but maybe not 🤔
18:50:57 <felixfontein> briantist: I'd definitely vendor the one from ansible-core, since that already might have been processed in some way :)
18:51:07 <briantist> maybe you meant that already, was ambiguous ;)
18:51:13 <felixfontein> I'll create a PR for vendoring that
18:51:24 <felixfontein> it definitely was ambiguous
18:51:48 <tadeboro> felixfontein: And another PR for de-vendoring in a few months ;)
18:52:35 <felixfontein> tadeboro: that's basically reverting this PR ;-)
18:53:00 <felixfontein> ok, thanks for your opinions on this!
18:53:03 <felixfontein> #topic open floor
18:53:11 <felixfontein> let's have an open floor before the hour is over :)
18:53:21 <felixfontein> does anyone have another thing to discuss today?
18:53:32 <gundalow> Nothing else from me
18:53:56 <briantist> thanks for leading the effort on this tricky issue felixfontein
18:54:03 <andersson007_> +1
18:54:54 <samccann> I'll be starting a community topic soonish on ...community/contributor guides and how we cover core vs collections vs ..erm  devtools like stuff when they come about etc.
18:55:38 <samccann> right now it's a hodgepodge in separate repos and a lot of the collection stuff isn't published yet on docs.ansible.com etc.
18:56:08 <andersson007_> thanks samccann !
18:59:51 <felixfontein> https://github.com/ansible-collections/community.general/pull/3984
18:59:51 <github-linkbot> https://github.com/ansible-collections/community.general/pull/3984 | open, created 2022-01-05T18:58:20Z by felixfontein: Use vendored copy of distutils.version [backport-3,backport-4] 
19:00:08 <felixfontein> ok, thanks everyone for attending this meeting :)
19:00:09 <felixfontein> #endmeeting