14:00:20 #startmeeting Ansible PR review day 14:00:20 Meeting started Wed Jun 17 14:00:20 2020 UTC. 14:00:20 This meeting is logged and archived in a public location. 14:00:20 The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:20 The meeting name has been set to 'ansible_pr_review_day' 14:01:14 Who's around? 14:01:34 hello everyone. 14:01:40 * felixfontein (partially) 14:02:52 * cybette lurking to observe and learn 14:03:42 resmo: misc you joining today? 14:05:14 #chair felixfontein cybette gregdek BhavyaM 14:05:14 Current chairs: BhavyaM cybette felixfontein gregdek gundalow 14:05:16 Hi all :) 14:05:33 #info What's this all about https://github.com/ansible/community/issues/407 14:05:59 Thanks for joining, this is very informal, so please do shout out at any point 14:06:30 #info If you are new to the Ansible Community I invite you to review the Code of Conduct https://docs.ansible.com/ansible/latest/community/code_of_conduct.html 14:06:51 #info This is the first PR review day since we've had the collections in place 14:07:02 BhavyaM: anything in particular you are hoping to get from today? 14:07:53 joining first time - looking forward to learning how this works. interested in contributing to ansible, ansible-runner and awx. 14:08:43 BhavyaM: excellent, please do shout out with questions. I'm sure there are other people lurking (idling in here) wondering the same thing 14:08:44 basically what extra is here compared to PR discussions on github. hopefully i get some insights into the codebase - while reviewing PRs and also insight into process of contributing 14:08:56 I hope today will help 14:08:59 :thumbs-up: 14:09:03 #topic community.general 14:09:49 #info We will start with https://github.com/ansible-collections/community.general/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc (oldest PR first) 14:10:08 https://github.com/ansible-collections/community.general/pull/52 Add check_and_failed option to pacemaker_cluster module 14:10:35 BhavyaM: basically I'm going to talk through what I see 14:11:23 there is no companion audio discussion anywhere. no discord or anything else, right ? 14:11:41 yep 14:11:44 yep 14:12:00 that PR definitely needs a rebase 14:12:00 BhavyaM: nop, just here. We've found this allows others to keep half an eye on things even if they are working on their dayjob 14:12:04 So looks like matbu has hit some issues when trying to rebase their PR. That's fairly common 14:12:09 #chair resmo 14:12:09 Current chairs: BhavyaM cybette felixfontein gregdek gundalow resmo 14:14:59 I've added some guidance here https://github.com/ansible-collections/community.general/pull/52#issuecomment-645400366 14:15:11 ok, next 14:15:22 https://github.com/ansible-collections/community.general/pull/53 Add pacemaker_resource module for managing cluster resources 14:16:29 53: By the same person as before, looks like it's already been reviewed, though no response in the past two months, I'll ask if they need help 14:16:51 sounds good 14:17:33 53: comment added 14:17:50 oh, and just for info I'm adding `pr_day` label to every PR we review today, helps us keep track 14:18:06 https://github.com/ansible-collections/community.general/pull/85 [WIP] Refactor github* modules,Added tests for github_deploy_key 14:18:30 85: the `[WIP]` means "Work In Progress", so we know this isn't complete yet 14:19:45 85: We can see from the last box there are "Conflicting files", meaning it needs a rebase and merge conflicts need resolving 14:20:36 shaps: FYI if you do backwards incompatible changes in #85, you should better get them done before 1.0.0 is released - otherwise you have to wait half a year 14:20:56 felixfontein: good point, could you add that to the Pr please? 14:21:36 done 14:21:46 community collections have a half yearly major release cycle ? 14:22:17 not necessarily, but community.general and community.network release major releases once every 6 months, and breaking changes can only go into major releases 14:22:30 felixfontein: what should `removed_in` be set to here https://github.com/ansible-collections/community.general/pull/85/files#diff-057fdbe9a63a4a64c8e81d41f6b7def7R24 14:22:37 changes that don't break backwards compatibility can get in earlier 14:23:13 gundalow: it already has been updated to 2.0.0 in master 14:23:22 ah, thanks 14:23:58 85: I'm reviewing each of the files now 14:26:39 85: Mostly looks OK, though there have been a lot of changes made to `master` since that PR was last rebased, so it's difficult to tell exactly what state it's in. Also this means that CI isn't running the right things 14:27:45 https://github.com/ansible-collections/community.general/pull/90 Add Thycotic DevOps Secrets Vault lookup plugin 14:28:54 85 contains a lot of reformatting, which makes reviewing hard and increases the chance of conflicts 14:29:51 yup 14:30:45 90: I see felixfontein has added lots of good review comments ~2 months ago, though no response. I'll ask if they need help 14:32:28 90: Do we have a helper method for https://github.com/ansible-collections/community.general/pull/90/files#diff-4c13096ce016b6d87593f79eaa1cfd09R101 14:32:38 hum, maybe the helper method is only for modules 14:35:09 hmm there is a helper, but I'm not sure anymore whether it's good for plugins too 14:35:33 the main motivation for the helper is to indicate which Python and which machine it needs to be installed on 14:35:42 which usually isn't a problem for the controller 14:35:51 yup, agreed 14:39:11 85: comment added, noticed they were doing work directly on `master` rather than a branch which may cause them future pain, so added some tips 14:39:48 https://github.com/ansible-collections/community.general/pull/91 Add the Thycotic Secret Server lookup plugin. 14:44:18 similar to #90, though for a different service 14:44:47 sry will be back later, 14:44:58 resmo: thank 14:45:56 o/ 14:46:04 #chair acozine 14:46:04 Current chairs: BhavyaM acozine cybette felixfontein gregdek gundalow resmo 14:46:09 acozine: mornin' 14:46:29 gundalow: afternoon! 14:46:30 acozine: o/ 14:46:54 cybette: hiya! 14:47:19 acozine: FYI we are working through https://github.com/ansible-collections/community.general/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc 14:47:49 https://github.com/ansible-collections/community.general/pull/129 parted: Allow passing negative numbers to specify partition boundary relative to disk end 14:47:58 thx 14:48:17 129: Oh, I remember seeing this before and it scared me a bit. Though that's partly due to a lack of understanding on my part 14:51:42 the author of that PR and ColOfAbRiX have been active in other parted PRs 14:52:09 if both of them want this change, I'm fine with merging it 14:52:22 it also makes ext2 it's default formatting mech for negative starting partitions - https://github.com/ansible-collections/community.general/pull/129/files#diff-fa4f2a01717420c0a32e0dfe52bdd326R629 14:52:23 ah, I didn't recognise the name 14:52:55 maybe i am misunderstanding. apologies if that's the case. 14:53:24 BhavyaM: it might already be the implicit default by parted, but I really don't know parted very well 14:53:43 BhavyaM: could you add that as a comment and ask whether this is potentially breaking backwards compatibility? 14:53:44 fstype default should be same whether partition starts from beginning or end though, right ? 14:54:30 ok. first contribution as comment on someone else's PR, without having any of my own contribution in their. that's going to go down really well. /s 14:54:34 doing that now. 14:54:54 BhavyaM: oh, don't worry about that :) 14:56:00 done. 14:56:16 https://github.com/ansible-collections/community.general/pull/129/files#r441609961 14:57:31 BhavyaM: congrats on your first comment! 14:57:50 hahaha 14:57:57 BhavyaM: woot 14:59:21 129 I see this is to address an old bug repo (2018) so I've asked the original bug filer if they want to review 15:04:05 are we going down the list from most recent to oldest? 15:04:10 or the other way around? 15:04:18 acozine: oldest to newest 15:04:19 or just picking ones we think might be merge-able? 15:04:43 going one at a time 15:04:47 * acozine actually looks at the sorting of that view 15:04:52 https://github.com/ansible-collections/community.general/pull/137 filesystem.py: fix xfs growfs 15:04:57 acozine: https://github.com/ansible-collections/community.general/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc 15:04:59 excellent, I'm with the program now 15:06:03 137: Not sure what https://github.com/ansible-collections/community.general/pull/137#issuecomment-639143063 means 15:06:39 me neither 15:06:48 I'll ask them for a review 15:10:02 137: I've pinged the creators of the original issue and previous PR to see if they can review 15:10:15 the functionality seems good; I can't usefully comment on the code itself 15:11:47 137: stale CI (CI is from 2020/05/15) so I'll trigger a rerun, which may give them some more things to fix 15:12:20 https://github.com/ansible-collections/community.general/pull/145 Add inventory alicloud_ecs 15:12:46 137: I'm hoping they will create a dedicated collection for these modules 15:13:06 https://github.com/ansible-collections/community.general/pull/153 Return correct values when running yarn in check mode 15:16:37 for PR153, is the change in line 225 only applicable when check mode is on? 15:19:52 * samccann strolls in late to the party 15:20:10 #chair samccann 15:20:10 Current chairs: BhavyaM acozine cybette felixfontein gregdek gundalow resmo samccann 15:20:26 Hey samccann ! 15:20:47 aaand gets hit w/ furniture! Hey gregdek ! 15:21:08 I'm not really a furniture thrower... 15:21:28 * gregdek glares angrily at his "rr" key that either repeats or dops letters... 15:21:28 I need to drop off for ~30mins 15:22:00 so people can feel free to take a break or continue 15:24:57 * acozine isn't expert enough at Python to review this PR well 15:29:42 acozine: yes, looks like line 225 only happens when check mode is on. Code looks good to me. 15:33:48 +1 for supporting check mode, that seems really useful 15:37:12 then let's get it merged! 15:40:25 \o/ 15:40:52 154 is failing CI 15:41:06 oh, and needs to be rebased 15:42:05 yes, and it already got a comment about that 9 days ago 15:42:20 moving on, then . . . 15:42:31 155 is also failing at the moment 15:43:09 it's a `version_added` failure 15:45:13 ah, looks like the OP hasn't pushed their latest code 15:45:22 so not a candidate to merge yet 15:45:38 yep 15:45:39 did we agree that ANSIBLE_METADATA was no longer required? 15:45:53 samccann: yes 15:45:59 ...and should we start mentioning that in PRs? (not holding them up but just adding a comment?) 15:46:17 sure, a suggestion would make that easy 15:46:18 ok I can add a comment then as an fyi 15:46:23 ok will do 15:46:35 and what should the version_added be for community.general? 15:46:36 sorry, just added a comment 15:46:51 acozine: also added a comment for that ;) 0.2.0 until in a couple of days, then 1.0.0 15:47:32 ah, yeah, I see the OP is fixing stuff in their local branch and marking the comments as addressed, just hasn't pushed those changes 15:47:48 felixfontein: sounds great, thank you! 15:48:12 169 is next 15:49:24 https://github.com/ansible-collections/community.general/pull/169 15:49:51 hmm what happens if I'd been using this as a comma separated string now that it's a list? 15:49:57 (aka is this a breaking change?) 15:50:13 it's compatible, normally you can provide a comma separate string for list options 15:50:24 oh, cool 15:50:49 the change seems useful, brings this module more into line with the rest of the packaging modules 15:50:50 TIL thanks shertel ! 15:51:44 there's no update to the tests, should there be? 15:51:45 that is one thing ansible has always made 'user friendly', lists can be comma separated strings 15:52:15 line 61 still has the comma version in the example... worth leaving there or should it be changed as well? 15:52:33 this made one of my early ansible attempts fail terribly when I tried to pass some string with a comma in it somewhere, and suddenly it was interpreted as a list :) 15:52:50 since both work, I'd vote for leaving the "old" example 15:52:58 felixfontein: the more common case is the inverse 15:53:12 and any programmer can figure out [ 'element, is', ] 15:53:13 felixfontein: heh, "surprise!" 15:53:19 bcoca: yes, and actually that helped me several times before that. it was only then that I really noticed what's going on ;) 15:53:37 its one of the few 'magics' that im happy with 15:53:44 fwiw not sure we should equate users with programmers 15:53:48 welcome dennis_effa, are you here to join the community PR review? 15:54:04 samccann: we dont, that is the point of having it autoconvert 15:54:57 mattclay: gundalow: felixfontein: ping - are the RHEL 7 and 8 tests always going to be real AWS instances? I'm realizing how fragile the tests are in docker in shippable for CentOS 7 and 8 because of the DBUS requirement and I kind of would rather just say "only run these tests on virtual machines" .... thoughts? 15:55:11 Thanks acozine I'd love to 15:55:21 #chair dennis_effa 15:55:21 Current chairs: BhavyaM acozine cybette dennis_effa felixfontein gregdek gundalow resmo samccann 15:55:22 I added a suggestion for the changelog fragment; can someone check if it's ok? if it is, I'll commit it and merge 15:55:31 maxamillion: i believe we use aws for rhel tests because it saves us from subscription headache 15:55:52 maxamillion: I think they will; there are other tests (like ufw tests) which already rely on this assumption 15:55:53 jtanner: I mostly just want to make sure they aren't going to be containers 15:55:59 felixfontein: +1 15:56:09 felixfontein: +1 for fixing the changelog fragment 15:56:12 back 15:56:26 jtanner: trying to test the firewall in a container seems a bit like the recipe for a bad time 15:56:32 gundalow: welcome back! 15:56:33 maxamillion: you can add `skip/docker` in aliases to avoid all docker-based CI targets 15:56:33 maxamillion: i don't think we can move to containers unless there's a service that can deal with the subscriptions 15:57:13 acozine: thanks, I'll add that change then 15:57:20 we're discussing PR 169 15:57:21 maxamillion: Yes, they're likely to always be VMs, although they may not always be on AWS. 15:57:26 jtanner: there likely never will be since the subscription manager dealings for RHEL containers injects the host's subscription when RHEL containers run on RHEL and I'd wager that criteria won't ever change because of support reasons 15:57:37 yep, agreed 15:57:40 mattclay: that's fine, I don't care about AWS so much as the VM aspect 15:57:42 jtanner: +1 15:57:44 mattclay: +1 15:57:48 felixfontein: +1 15:57:52 dennis_effa: we're going through a list of open PRs on community.general: https://github.com/ansible-collections/community.general/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc+ 15:58:10 +1 on changelog fragment update 15:58:11 to see how many we can merge or move forward 15:58:30 samccann: thanks! 15:58:40 maxamillion: You can use `skip/docker` to avoid the docker hosted instances on Shippable for that test. 15:58:51 Oo alright acozine 15:59:06 mattclay: +1 - yeah, I saw felixfontein suggest that and I think that's exactly what I'll do 15:59:14 dennis_effa: This is all fairly informal. So feel free to ask about anything at anypoint. 15:59:18 hmm, someone cancelled the shippable run> 15:59:19 ? 15:59:44 We generally do 15:59:44 169: $some_comments (where 169 is the PR, so people know which of the many PRs we are talking about) 16:00:29 I will gundalow 16:00:42 oh someone posted recently that shippable is having problems... lemme dig up the message 16:01:13 sounds like this is the case, since now there are two CI runs for my change, and the one github is showing is cancelled, while the other is running 16:01:22 "Shippable is having issues with authentication this morning. As profiles are being re-synced they're losing access to GitHub accounts, effectively limiting access to public projects, and read-only. " 16:01:32 heh. and now github switched to success... 16:01:33 dunno if that's the cause? 16:01:49 hmm, probably unrelated, but that explains some other issues I'm having with it 16:01:56 heh 16:02:02 felixfontein: That sounds like auto-cancel when a PR is updated with additional commits. 16:02:05 alright, for PR review .... where should I be working/tracking? 16:02:11 sorry I'm late to the party :) 16:02:21 #chair maxamillion 16:02:21 Current chairs: BhavyaM acozine cybette dennis_effa felixfontein gregdek gundalow maxamillion resmo samccann 16:02:59 maxamillion: we are going through https://github.com/ansible-collections/community.general/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc (top to bottom, ie oldest to newest) 16:02:59 Currently on `169` 16:03:05 mattclay: btw, do you know why shippable says "2018 © Shippable.", and their changelog (https://app.shippable.com/changelog) ends in 2018? 16:03:27 gundalow: do I just shout out if I'm working on one? 16:03:36 mattclay: just looking at that I would assume it is dead, but it's still there... :) 16:03:39 gundalow: or tag myself a reviewer or something? 16:03:46 felixfontein: They've stopped updating the service since being acquired by JFrog. They have a new service they're working on, JFrog Pipelines. 16:03:47 maxamillion: I've been doing `169: Reviewing code` 16:04:03 OK, shippable isn't letting me rerun 16:04:05 gundalow: just throwing that in channel or elsewhere? 16:04:07 169: I'll merge 16:04:10 mattclay: oh ok. 16:04:41 OK, next 16:04:51 https://github.com/ansible-collections/community.general/pull/175 add EfficientIP Device Manager dynamic inventory 16:05:00 175: Brand new inventory script 16:05:22 175: has `stale_ci`, so can't be merged as is 16:05:40 needs a changelog fragment 16:06:00 #action if 175 gets merged update BOTMETA to add to remote_management label & maintainers 16:06:12 175: Examples use FQCN, which is good 16:06:14 samccann: nope because it is a new plugin 16:06:29 175: definitely needs tests 16:06:50 so we don't document new plugins only new modules? 16:07:00 (in a changelog/porting guide entry) 16:07:59 samccann: these are auto-documented, the changelog generator adds a comment on them 16:08:02 samccann: no need. The changelog scripts automagically add new plugins to the changelog file 16:08:05 like in ansible/ansible 16:08:15 ah gotcha... thanks 16:08:47 175: I don't really know anything about dynamic inventory scripts, so I can't add much 16:09:47 I added some generic comments 16:11:39 does EfficientIP belong in community.network? 16:11:43 sorry 16:11:51 175: does EfficientIP belong in community.network? 16:11:58 175: I have no idea what EfficientIP actually is :) 16:12:28 175: acozine: could well be though! 16:12:44 175: quick search returns `EfficientIP, a leading provider of network services, ` 16:13:10 https://www.efficientip.com/products/ 16:13:28 can you suggest to move it there? 16:13:31 net_tools landed in community.general. seems this belongs there 16:13:32 nop 16:13:53 it's remote management (network serial interface), iLOM, etc 16:14:03 ok 16:14:13 Good to check though 16:14:32 cool 16:16:17 so, on to 182? or is there more we can do to get 175 a step farther along? 16:16:58 182: Skip, NIOS should be moving to it's own collection 16:17:46 https://github.com/ansible-collections/community.general/pull/209 cpanm: Honor version operators 16:17:49 maybe add a comment where this is moved? I have no idea 16:20:21 182: added two comments 16:20:41 #action gundalow chase status of NIOS collection. Direct current PRs in c.general to new location 16:20:45 182: I really don't like this `curl xxx | sudo yyy` idiom 16:24:33 nop, me neither, though it's inside an integration tests, and I'm glad they've added tests 16:28:38 https://github.com/ansible-collections/community.general/pull/216 lxc_container: fix the type of the 'container_config' parameter 16:29:03 I need to drop off to get some food 16:32:34 216: added a short review 16:36:12 216: CI failures look bogus - everything failing in the first minute? 16:36:45 er, three minutes, but still . . . 16:37:45 if they add the docs felixfontein asked for, it should kick off a new CI run 16:38:12 yep 16:38:31 tho is it worth giving it a kick now in case there are some real errors there? 16:38:57 if shippable is feeling better, yeah; if not, then we don't want to pile on 16:39:07 v. true 16:40:10 Those errors don't appear to be related to the Shippable issue. 16:40:25 `ERROR! Collection tar at '/root/.ansible/tmp/ansible-local-637NB7iF_/tmpzI0jSL/cisco-intersight-1.0.5.tar290IT7.gz' does not contain the expected file 'releases/cisco-intersight-1.0.4.tar.gz'` 16:42:13 mattclay: ah, interesting 16:42:54 the collection expects 1.0.5 to contain 1.0.4 . . . 16:43:11 That looks like a collection published that contains previously published versions. 16:43:19 Or at least an attempt to do so. 16:44:02 or maybe a failure to update some config file when the new version got published? 16:45:25 cd 16:45:34 Sorry, wrong window. :) 16:45:47 heh 16:49:06 acozine: I downloaded that collection and verified it was published wrong, but there's a new version that appears to be fixed. 16:49:40 mattclay: thanks 16:50:39 216: I don't fully understand why the tests are downloading the `cisco-intersight` collection for a change to `cloud/lxc` in `community.general` 16:53:01 however, it's clear that we won't be merging that PR today 16:55:03 how about 218? https://github.com/ansible-collections/community.general/pull/218 16:56:06 218: -1 for ignoring the docs errors: https://github.com/ansible-collections/community.general/pull/218/commits/755f67e5ed146f0a083ca72b8599c8940fdc7a60 16:57:37 though to be fair, the other NIOS modules also ignore those errors 16:57:44 this is another infoblock/nios PR. Should get the same treatment as the other one (going to another collection) 16:58:05 (sorry Infoblox) 16:58:31 ah, okay, same for 219 then 16:58:54 yep 16:59:41 228 should be a `*_info` module 17:00:25 was requested to close a bit back. Any reason we shouldn't just close it now? 17:01:41 I'd vote to close it 17:02:30 +1 17:03:08 mind you I have no rights in this repo so can't do it myself. 17:10:14 re 17:11:22 the cisco.intersight packaging problem has been reported (no idea whether it was fixed), and we fixed an older version which is known to work, so kicking CI should help 17:11:40 looks like I can't close the PR either 17:12:03 acozine: I think gundalow said above that the nios modules will move somewhere 17:12:20 yeah, samccann noted that too 17:12:22 and new modules should not have new ignore.txt entries if possible 17:12:28 sorry, reading through backlog :) 17:13:05 :-) 17:14:16 I'll close 228 17:14:30 kept it open long enough :) 17:17:15 heh, okay 17:17:21 I put a comment on it as well 17:17:59 229? 17:18:19 * acozine needs some food soon 17:18:51 needs a changelog fragment 17:18:55 my food is just warming up :) 17:20:33 for #237 - splunk now has a community repo - https://github.com/ansible-collections/community.es 17:20:36 229: I have no idea whether that change is correct or not, I guess a maintainer has to look 17:20:55 is this another scenario where we should request the module be migrated? 17:21:07 (for 237...sorry jumped ahead) 17:21:11 "es" is a not really helpful name :) 17:21:25 no problem for jumping 17:21:50 maxamillion: are you planning to migrate the splunk module(s) from community.general to community.es? 17:21:59 (or know of someone who will do that?) 17:22:01 heh, I assume `es` for Espana 17:23:13 felixfontein: yes 17:23:16 clearly not the case here 17:23:23 I'm more thinking of https://en.wiktionary.org/wiki/es#Etymology_1_6 but Spain would be next on list :) 17:23:38 maxamillion: can you mention that in https://github.com/ansible-collections/community.general/pull/237 ? so the PR author knows what to do 17:23:39 it matches the Supported collection name fwiw 17:23:54 ansible.es? 17:23:59 sounds like a domain name ;) 17:24:06 and yes, the namespace isn't exactly the best but community.enterprise_security was considered way too verbose for any realistic FQCN usage 17:24:16 maxamillion: true :) 17:24:37 and `ent_sec` sounds like a Tolkien reference 17:25:35 :) indeed 17:26:21 heh 17:27:50 I hope to one day replace them with a `community.splunk` collection but there's a lot of work that would need to be done before that stuff could be considered general purpose splunk, as it stands now it depends on REST API endpoints that only exist if the splunk instance has the Splunk Enterprise Security SIEM add-on installe 17:27:52 installed* 17:27:56 which is fun 17:30:53 back 17:32:39 wb 17:32:44 mattclay: FYI I raised an issue for cisco-intersight 1.0.4 vs 1.0.5. Also we pinned the version we install during c.general testing to an older version. I'll trigger a rerun on 216 17:33:03 * felixfontein just found some ingredients in the fridge I wanted to put into lunch (I just finished eating dinner) 17:33:25 * acozine is going to go look through the fridge for lunch 17:33:25 #action rerun CI on c.general 216 17:37:27 btw, are we doing the community meeting at 18:00 UTC (i.e. in 23 mins)? 17:38:08 I guess the main topic (from my POV) is deciding on when (and how) 1.0.0 is released, which would be nice to fix :) 17:39:05 felixfontein: oh, I'd forgotten about that 17:39:10 (and then there are some things by cyberpear and abadger1999) 17:39:10 thanks for the reminder 17:40:23 np 17:41:46 next is https://github.com/ansible-collections/community.general/pull/241 then? 17:42:55 I can add the addendum to the changelog fragment to include the PR 17:43:03 Fix the behavior of ipa modules in case IPA_HOST is empty #241 17:43:21 samccann: would be great! 17:44:00 241: Never used it, though looks sensible 17:44:22 +1 to merge 17:44:52 samccann: ah, thanks for comment 17:45:09 I can commit that to their branch then hit merge? 17:45:14 need to drop and go heads-down for README file updates. 17:45:29 samccann: Thanks as always 17:45:36 tiggi and Akasurde made chnages to the ipa module recently 17:45:40 gundalow: sometimes it works for me to just commit the suggestion in the PR itself and then merge 17:45:46 if we want more opinions, we should ask them 17:45:51 but merging is fine for me too 17:45:52 241 merged 17:46:10 https://github.com/ansible-collections/community.general/pull/250 Handle negative integer values in osx_defaults 17:46:46 looks sensible, but needs a changelog fragment 17:46:55 250 adding a comment 17:47:45 ah, andersson007_ already asked for a fragment 17:47:53 1.5 months ago 17:48:17 https://github.com/ansible-collections/community.general/pull/263 New merge lists plugin from a given key 17:48:42 this looks like a very specialized plugin to me, and I'm not sure it belongs in c.g 17:49:28 I don't know where the two users are coming from which added a thumbs-up after I asked the author to find more people who want something like that 17:49:54 looks a bit suspicious like friends returning a favor, since nobody wrote anything except a thumbs-up 17:50:13 comment added 17:50:27 yup, I've asked them for feedback 17:51:28 I also asked them to say what they would use it for 17:52:31 Good call 17:54:41 https://github.com/ansible-collections/community.general/pull/267 Fixed flatpak module to accept a list of names to install/uninstall 17:57:43 needs rebase and potentially tests 17:59:19 I wrote something 18:00:24 Thanks 18:00:34 How are people doing, should we call it a day? 18:00:41 (and swap to Community meeting) 18:01:11 we can also continue after the community meeting if people are still interested (though I'm not sure I will be - probably not) 18:01:37 we are missing two interesting PRs though: https://github.com/ansible-collections/community.general/pull/271 and https://github.com/ansible-collections/community.general/pull/289 18:02:10 the first needs more knowledge on action plugins (which I don't have), and the second should better get resolved before we release 18:02:22 (it was pretty inactive though) 18:02:34 (and nobody responded to my question 9 days ago) 18:06:07 ok. should we switch to the community meeting? 18:06:50 yes 18:06:52 #chairs 18:06:55 #chair 18:06:55 Current chairs: BhavyaM acozine cybette dennis_effa felixfontein gregdek gundalow maxamillion resmo samccann 18:06:57 Thank you all 18:06:57 andersson007_: cyberpear: gundalow: acozine: samccann: 18:06:59 #end meeting 18:07:01 #endmeeting