18:00:13 <felixfontein> #startmeeting Ansible Community Meeting
18:00:13 <zodbot> Meeting started Wed Oct  6 18:00:13 2021 UTC.
18:00:13 <zodbot> This meeting is logged and archived in a public location.
18:00:13 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:13 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:13 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:13 <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:17 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:23 <felixfontein> #chair gundalow dmsimard jillr abadger1999
18:00:23 <zodbot> Current chairs: abadger1999 dmsimard felixfontein gundalow jillr
18:00:25 <briantist> o/
18:00:27 <dmsimard> o/
18:00:38 <andersson007_[m]> o/
18:00:46 <abadger1999> Bom dia!
18:00:58 <felixfontein> #chair briantist andersson007_[m]
18:00:58 <zodbot> Current chairs: abadger1999 andersson007_[m] briantist dmsimard felixfontein gundalow jillr
18:01:03 * cybette not here full time, in another meeting
18:01:17 <felixfontein> #chair cybette
18:01:17 <zodbot> Current chairs: abadger1999 andersson007_[m] briantist cybette dmsimard felixfontein gundalow jillr
18:01:44 <felixfontein> #topic Updates
18:02:11 <cidrblock[m]> hello all
18:02:12 <felixfontein> #info ansible-core 2.12.0b1 has been released
18:02:17 <felixfontein> #chair cidrblock[m]
18:02:17 <zodbot> Current chairs: abadger1999 andersson007_[m] briantist cidrblock[m] cybette dmsimard felixfontein gundalow jillr
18:02:24 <dmsimard> #info Ansible 5.0.0a1 has been released
18:02:57 <felixfontein> \o/
18:03:16 <dmsimard> #info We had a great Ansible Contributor Summit last week, we'll have a blog post about it sometime in the near future
18:03:27 <abadger1999> Yay!
18:04:12 <abadger1999> On a different note, I'm going to be taking some PTO and then leaving Ansible.
18:04:30 <tadeboro> o/
18:04:52 <dmsimard> abadger1999: we talked about it already but you'll be missed :(
18:04:53 <felixfontein> #chair tadeboro
18:04:53 <zodbot> Current chairs: abadger1999 andersson007_[m] briantist cidrblock[m] cybette dmsimard felixfontein gundalow jillr tadeboro
18:04:58 <abadger1999> I'm going to resign my committee seat effective after today's meeting to free it up to someone who will have more time to participate as well.
18:05:08 <felixfontein> abadger1999 will definitely be missed!
18:05:16 <jillr> abadger1999: oh no, you will be missed! I hope your next adventure is amazing
18:05:22 <abadger1999> Aww, thanks folks :-)
18:05:22 <andersson007_[m]> yeah
18:05:28 <felixfontein> (should we #info this somehow?)
18:05:31 <cidrblock[m]> abadger1999: you will be missed by many! (maybe even me :))
18:05:39 * acozine waves
18:05:44 <felixfontein> #chair acozine
18:05:44 <zodbot> Current chairs: abadger1999 acozine andersson007_[m] briantist cidrblock[m] cybette dmsimard felixfontein gundalow jillr tadeboro
18:06:03 <abadger1999> #info abadger1999 will be moving on to new pastures after today's meeting.
18:07:21 <felixfontein> from what I heard there will be an email soon from gundalow with more information to the steering committee members
18:07:44 <gundalow> Correct
18:07:47 <felixfontein> ok, if there are no more updates, let's start with discussions :)
18:07:55 <gundalow> We are always looking for new people to join
18:08:00 <gundalow> oh, one more update
18:08:41 <gundalow> #info Ansible Community Labs are now online https://www.ansible.com/products/ansible-community-training feedback very welcome via https://github.com/ansible/instruqt/discussions/54
18:08:47 <gundalow> Thanks, that's all I had
18:08:55 <felixfontein> #topic Change the date of the first ansible 5 maint release
18:08:56 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/45
18:09:33 <felixfontein> while talking about releases we noticed that there were 5 weeks between the planned 5.0.0 and 5.1.0 releases, which was mainly due to the 5.1.0 date not being updated after the 5.0.0 date was moved forward by a week
18:10:18 <dmsimard> The doc change has already been merged, did we intend to discuss this prior ?
18:10:22 <felixfontein> the proposal (which already got merged, but we can undo that if we don't agree) is to release 5.1.0 before winter break, on 2021-12-21, which is 3 weeks after the 5.0.0 release
18:10:31 <abadger1999> Yeah, I should have marked it WIP until after the meeting.
18:10:32 <acozine> Solstice Release sounds good to me
18:10:39 <felixfontein> dmsimard: we didn't
18:10:58 <felixfontein> does anyone wants to discuss this, or should we vote? I would think it's rather uncontroversial
18:11:02 <jillr> it LGTM
18:11:02 <abadger1999> (but as felixfontein says, we can always revert it if we decide not to approve it)
18:11:13 <dmsimard> LGTM as well
18:11:40 <felixfontein> VOTE: should we move the 5.1.0 planned release date to 2021-12-21, i.e. 3 weeks after 5.0.0?
18:11:43 <felixfontein> +1
18:11:44 <tadeboro> +1
18:11:46 <jillr> +1
18:11:48 <acozine> +1
18:11:48 <dmsimard> +1
18:11:53 <abadger1999> +1
18:12:01 <cidrblock[m]> +1
18:12:29 <cybette> +1
18:12:30 <gundalow> +1
18:12:53 <andersson007_[m]> +1
18:13:10 <felixfontein> #agreed we move the 5.1.0 planned release date to 2021-12-21, i.e. 3 weeks after 5.0.0
18:13:13 <felixfontein> cool :)
18:13:18 <felixfontein> thanks!
18:13:19 <felixfontein> #topic Proposed release schedule for community.general (upcoming major 4.0.0 release)
18:13:23 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/46
18:13:26 <felixfontein> and another related one ;)
18:14:08 <felixfontein> basically I propose to continue with a three-week cycle, which fits well with both the Ansible 4 and Ansible 5 release schedule, and bump to community.general 4.0.0 after the next minor release (which will be 3.8.0)
18:14:30 <dmsimard> That sounds reasonable and sensible
18:14:38 <felixfontein> so the 4.0.0 release will be a couple of days before the deadline for breaking changes in Ansible
18:14:57 <felixfontein> does anyone wants to discuss this?
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:43 <felixfontein> VOTE: release community.general 4.0.0 after the next 3.8.0 minor release and continue with a regular three-weeks schedule
18:15:51 <abadger1999> +1
18:15:55 <jillr> +1
18:15:59 <andersson007_[m]> +1
18:16:01 <acozine> +1
18:16:12 <felixfontein> +1
18:16:17 <tadeboro> +1
18:16:19 <cybette> +1
18:16:21 <dmsimard> +1
18:16:45 <cidrblock[m]> +1
18:17:21 <gundalow> +1
18:17:21 <felixfontein> #agreed release community.general 4.0.0 after the next 3.8.0 minor release and continue with a regular three-weeks schedule
18:17:34 <felixfontein> cool :) already two topics done for today ;)
18:17:45 <felixfontein> I have another one which will hopefully be quick as well:
18:17:46 <felixfontein> #topic Clarify Python version restriction documentation
18:17:46 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/47
18:17:50 <andersson007_[m]> let's keep the current pace:)
18:18:47 <felixfontein> this is something I *thought* was already in there (I did remember we discussed it and even voted on it), but right now it's only mentioned in the checklist that Python requirements that are different from the 'general Ansible Python requirements' have to be mentioned in the README
18:18:59 <jillr> I reviewed the PR but for the sake of completeness, +1  :)
18:19:18 <dmsimard> It feels odd to me to specify which versions of python are unsupported vs specifying those that are supported
18:19:29 <felixfontein> it's a bit more explicit than what we voted on in February
18:19:34 <jillr> (also I'm having ISP issues so if I vanish suddenly, that's probably why)
18:19:49 <andersson007_[m]> felixfontein: i think we should also fix the checklist correspondingly
18:20:04 <felixfontein> dmsimard: I think saying which ones are unsupported is basically equivalent to which ones are supported
18:20:19 <andersson007_[m]> i.e. to put both the statements in it
18:20:43 <felixfontein> andersson007_[m]: I think the checklist already says something like that: supports Python 2.6 or greater and Python 3.5 or greater. If it does not, read the [full guidelines](https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#python-compatibility) to see if you qualify for an exception and document the unsupported [Python
18:20:44 <andersson007_[m]> if the committee agrees on the changes
18:20:48 <felixfontein> versions](https://docs.ansible.com/ansible/latest/dev_guide/developing_python_3.html#ansible-and-python-3) in the collection ``README.md`` and in every module and plugin (or in doc fragments)
18:20:49 <dmsimard> felixfontein: by that I mean that by declaring the versions that are supported, you are already excluding those that are unsupported and that feels sufficient -- in other words, if it's not there, it's not supported
18:21:05 <acozine> I'd add a link to the page in the ansible/ansible docs where we talk about python versions
18:21:08 <andersson007_[m]> felixfontein: yes, it says but not so precise
18:21:20 <felixfontein> dmsimard: right now some collections don't support all versions, but do not say so in the README
18:21:42 <felixfontein> dmsimard: mentioning either wihch ones are suppoted, or which ones are not supported, would be a big improvement IMO
18:21:46 <dmsimard> felixfontein: oh, so by all means they should mention the versions that are supported
18:22:13 <briantist> the key missing piece in this chat discussion is the differentiation between what the "Ansible" (presumably ansible-core) supports, vs. what the collection supports
18:22:15 <felixfontein> acozine: there's aleady a link to that at the beginning of the main section on Python versions
18:22:24 <dmsimard> but again, it feels unncessary to say that python 2.7 isn't supported if you're already saying that, for example, py >=35 is required
18:22:31 <acozine> felixfontein: ah, okay, that works
18:22:49 <abadger1999> Reading the past approval, perhaps the information being in the DOCUMENTATION should be a MUST even when it is also mentioned in the README?
18:22:55 <felixfontein> briantist: I think that's already in that section which contains this subsubsection
18:22:57 <briantist> so while saying affirmatively that the collection supports py versions x, y, & z does exclude any not listed, it seems like the point of this is to emphasize the differences between ansible-core support python versions
18:23:11 <briantist> right,  it's in your diff
18:23:43 <andersson007_[m]> felixfontein: just imo would be nice to have them in the check list too instead of the current line OR to make the current wording in the check list more general
18:23:48 <briantist> I'm saying dmsimard has a point more generally, but maybe is not seeing that this is to emphasize support compared to core
18:24:37 <briantist> dmsimard: would you say that's accurate? or you think it's not necessary to call out differences between core supported versions not supported by the collection?
18:27:10 <felixfontein> briantist: how would you formulate it?
18:27:17 <dmsimard> I realize there is a distinction from core but I don't think it's necessary to call out that py27 is unsupported if the collection has already specified that it required py >=35 (for example)
18:27:28 <briantist> got it, ok! my mistake then
18:27:52 <briantist> felixfontein: I think it's formulated fine for the intent, just seemed like the distinction might have been missing from the chat discussion
18:28:06 <briantist> FTR I don't feel strongly either way on this requirement
18:28:20 <dmsimard> so to me, that's a YES to MUST specify supported versions of python -- I'm not going to prevent collections to specify that they don't support py27 if they want to but I would not make that a requirement
18:29:00 <felixfontein> dmsimard: so how would you write it?
18:29:55 <dmsimard> I can propose something in the PR
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:12 <felixfontein> ok. let's continue the discussion next week then.
18:30:20 <dmsimard> ++
18:30:32 <felixfontein> resp. let's continue it during the week in an async fashion in that issue / PR :)
18:30:39 <dmsimard> by all means
18:30:48 <felixfontein> ok, next topic then!
18:30:52 <felixfontein> #topic Collection requirements: expanding the section on best practices
18:30:55 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/33
18:31:05 <felixfontein> the never-ending resource module discussion :)
18:31:41 <felixfontein> gundalow: acozine: cyberpear: you haven't yet voted on this one
18:31:42 <dmsimard> if I may, can we get to two other topics which might be a bit more time sensitive ?
18:31:57 <dmsimard> oh, wait, the resource module is time sensitive too
18:32:02 <felixfontein> yes... :)
18:32:06 <tadeboro> dmsimard: This one is also time sensitive ;)
18:32:21 <dmsimard> ¯\_(ツ)_/¯
18:32:39 <abadger1999> It's interesting that thaumos voted yes but also said we should be finding compromise. It would be nice if he could explain that.
18:33:06 <cidrblock[m]> I know that gundlow plans to comment, but didn't get a chance before PTO. Can we wait for his feedback?
18:33:17 <acozine> I haven't voted because I don't have a strong opinion.
18:34:04 <felixfontein> acozine: if you want to abstain you could write that as your vote
18:34:33 <dmsimard> One thing that I would point out is that there were various sessions about resource modules at AnsibleFest and Contributor Summit
18:35:07 <tadeboro> cidrblock[m]: As far as I am concerned, we can wait, but this does mean that we are also delaying the deepsec collection decision.
18:36:02 <jillr> what's the current vote count?  does anyone know?
18:36:54 <jillr> I'd prefer not to leave this one to drag out if we can avoid it
18:36:56 <tadeboro> jillr: Mostly yes to accepting resource modules as a way of structuring content.
18:37:14 <jillr> do we have enough votes to proceed with a decision?
18:38:02 <tadeboro> But I did not count the votes. Let me try to do that now.
18:38:06 <felixfontein> I think it's 3x-1, 5x+1 when looking at steering committee votes
18:38:20 * jillr is also trying but ISP lag is interferring
18:38:53 <felixfontein> (I hope I didn't miscount, there are a lot of posts and GH starts hiding some, and many people wrote multiple posts :) )
18:40:11 <felixfontein> where -1 means "restrict resource modules to network + (maybe) security", and +1 "allow resource modules everywhere". I don't think there really was something inbetween
18:40:33 <cidrblock[m]> As a courtesy, I think we should wait for gundalow, I do know he did want to weigh in here
18:40:35 <jillr> felixfontein: sounds like we should probably wait for gundalow to return then
18:40:58 <abadger1999> I think most who voted -1 also voted +1 to most of the compromises.
18:42:15 <gundalow> I've added a comment https://github.com/ansible-community/community-topics/issues/33#issuecomment-936880511
18:42:29 <felixfontein> abadger1999: there wasn't anything between "allow for network + security" and "allow everywhere" (except one suggestion to also allow it for modules that handle REST APIs, but I think nobody really commented on that one)
18:42:30 <tadeboro> I came back with the same numbers as felixfontein. And one +0 for acozine, which makes it 3x-1, 5x+1, 1x0, which still can go either way.
18:42:31 <cidrblock[m]> there he is :)
18:43:12 * gundalow votes for inclusion (given we will work together to improve RMs and the proposal process generally)
18:43:38 <abadger1999> felixfontein: ah, yeah, the other options were outside of that boundary.
18:44:00 <felixfontein> gundalow: do you mean inclusion of that collection, or inclusion of resource modules as a general concept that can be used everywhere?
18:44:03 <abadger1999> felixfontein: I'll note that my option wasn't presented before other people had voted either.
18:44:56 <gundalow> felixfontein: +1 to both
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:46:03 <tadeboro> With gundalow's +1, we get to 3x-1, 6x+1, 1x0 to accepting resource modules as an official way of writing modules, and that is enough to pass.
18:46:16 <felixfontein> ok, so it looks like we have 6 x "allow resource modules everywhere", 3 x "restrict them to all of network/security (or even less)", and 1 x no strong opinion either way
18:46:36 <felixfontein> good that we ended up on the same numbers :)
18:46:59 <gundalow> If there are ways we can improve this (or the process more generally) PLEASE talk to me, DMs are open
18:47:08 <gundalow> #info If there are ways we can improve this (or the process more generally) PLEASE talk to me, DMs are open
18:47:28 <jtanner> hi
18:47:29 <felixfontein> #agreed we accept resource modules as a valid concept for all areas
18:47:33 <dmsimard> ansible/proposals is the only thing that comes to mind but it has been under-utilized IMO
18:47:41 <felixfontein> (I hope I formulated this #agreed correctly, if not please tell me ASAP!)
18:47:47 <felixfontein> #chair jtanner
18:47:47 <zodbot> Current chairs: abadger1999 acozine andersson007_[m] briantist cidrblock[m] cybette dmsimard felixfontein gundalow jillr jtanner tadeboro
18:48:19 <felixfontein> dmsimard: I fully agree
18:48:37 <felixfontein> (I'm also not 100% sure whether ansible/proposals is mainly for core, or for 'all of Ansible')
18:48:49 <dmsimard> there's a little bit of that too, yes
18:49:00 <dmsimard> it has presumably been about (what is now) ansible-core
18:49:07 <tadeboro> Thank you all for pitching in here. I will write the conclusion in the ticket and close it down.
18:49:27 <felixfontein> tadeboro: thanks a lot!
18:49:42 <felixfontein> ok, then we have a little bit of time for one more topic:
18:49:43 <felixfontein> #topic Deprecation of servicenow.servicenow in favor of servicenow.itsm
18:49:46 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/44
18:49:48 <gundalow> Thanks everybody, I know this has been one of the longer discussions, though for me, there's been a lot of good feedback and ideas along the way
18:49:55 <felixfontein> dmsimard: do you want to present this?
18:49:59 <dmsimard> yes
18:50:05 <dmsimard> I will try to make this quick because I have another topic :p
18:50:28 <felixfontein> (just one...? :D )
18:50:36 <dmsimard> In essence, servicenow.servicenow now has a big DEPRECATED message at the top of their README: https://github.com/ServiceNowITOM/servicenow-ansible
18:50:44 <cidrblock[m]> TY all, I know that was a long road, next step are to make sure the defintion of what a resourc emodule is and how it operates is well documented. We can lift some details from early in the issue.  What we don't want to happen is to see half-resource modules or a hybrid, or half implemented one
18:51:35 <dmsimard> This collection is in the Ansible community package but it's purported replacement, servicenow.itsm, is a different collection without necessarily providing an "upgrade" path from servicenow.servicenow
18:52:04 <andersson007_> cidrblock[m]: +1
18:52:11 <dmsimard> I have talked to various stakeholders and it does not appear that servicenow.itsm is currently seeking inclusion in the community package
18:52:43 <dmsimard> My suggestion would be to keep servicenow.servicenow in Ansible 5 because it has just been deprecated and remove it for Ansible 6
18:53:05 <dmsimard> If servicenow.itsm wants to be included in the package, they can do it in time for Ansible 6
18:53:33 <dmsimard> In the meantime, I would encourage servicenow.servicenow to add deprecation notices in the modules (rather than just in the readme) so that the word can get out
18:53:56 <dmsimard> That's what I have, does that sound sensible ?
18:54:00 <acozine> that sounds like a reasonable approach
18:54:24 <felixfontein> dmsimard: I don't think the currently released version of servicenow.servicenow is deprecated. there's only this little notice in the GH repo
18:54:37 <dmsimard> felixfontein: right, that is my understanding as well.
18:54:37 <acozine> to me, it feels a bit late to be removing collections from Ansible 5
18:54:47 <dmsimard> felixfontein: I found out about the deprecation by complete accident
18:55:03 <jillr> iirc service now is deprecating the API that collection uses, but I don't know much details
18:55:19 <felixfontein> in any case, I think we should stick to a long enough deprecation cycle (if there are no reasons why it has to be extremely quick), so we would have to announce the deprecation for 5.0.0 so we can remove it for 6.0.0 (or even just in 7.0.0?)
18:55:48 <felixfontein> I'm not sure whether though whether this is something we have to start, or whether the collection owners should request deprecation/removal
18:56:14 <dmsimard> 7 is pretty far out (a year from now) and users can still install it from galaxy if they want, I would not carry it for longer than 5
18:56:16 <felixfontein> because right now we are only acting on this little notice in the repo, and we have no other information on what their plans are
18:56:22 <gundalow> > iirc service now is deprecating the API that collection uses, but I don't know much details
18:56:22 <gundalow> Well that might solve it for us fairly quickly
18:56:25 <jillr> we could reach out to the collection owners and say, "hey, what's up with this README comment?"
18:56:36 <gundalow> * >
18:56:36 <gundalow> iirc service now is deprecating the API that collection uses, but I don't know much details
18:56:36 <gundalow> Well that might solve it for us fairly quickly
18:56:36 <tadeboro> I agree here: just treat the collection as supported for now since there is not much that could break in that collection and work with maintainers on proper deprecation proces.
18:56:39 <dmsimard> jillr: we have though the discussion has not been public
18:56:51 <jillr> ah ok, nevermind me then  :)
18:57:14 <cyberpear> any idea how fast SNow removes an API after deprecation? if it sticks around for a while, probably fine to keep the collection available too
18:57:22 <felixfontein> #chair cyberpear
18:57:22 <zodbot> Current chairs: abadger1999 acozine andersson007_[m] briantist cidrblock[m] cyberpear cybette dmsimard felixfontein gundalow jillr jtanner tadeboro
18:57:23 <andersson007_> tadeboro: +1
18:57:31 <tadeboro> If the ServiceNow table API goes away, this will "solve" ther serviceNow problem in its entirety becase servicenow.itsm also uses it ;)
18:57:58 <jillr> I have a hard stop at the top of the hour but I'm +1 to keep that collection in Ansible 5 and until we have more info
18:58:18 <tadeboro> But I would imagine that that API will not vanish over the night.
18:58:33 <dmsimard> VOTE: Keep servicenow.servicenow included in Ansible 5 and consider removing it for Ansible 6
18:58:43 <cyberpear> +1
18:58:44 <gundalow> Can we add deprecation notes inside the collection now which point to the README, therefore we can update as we know more
18:58:44 <dmsimard> +1
18:58:51 <gundalow> +1
18:58:56 <felixfontein> -1 since I don't think we should remove it in 6 if we don't deprecate it for 5.0.0
18:59:06 <dmsimard> felixfontein: it is already deprecated
18:59:20 <tadeboro> +1
18:59:22 <felixfontein> dmsimard: the released collection is not deprecated
18:59:51 <felixfontein> (in particular, there is no changelog / porting guide entry saying that it is deprecated)
18:59:58 <andersson007_> -1
19:00:02 <abadger1999> +0
19:00:17 <dmsimard> felixfontein: right, I mentioned earlier > I would encourage servicenow.servicenow to add deprecation notices in the modules (rather than just in the readme) so that the word can get out
19:00:25 <acozine> Same here. Hard stop in one minute. +1 to keeping servicenow.servicenow in Ansible 5 and removing it in Ansible 6.
19:00:43 <cyberpear> I agree w/ felixfontein no need to remove in 6 if it's still usable
19:00:53 <felixfontein> actually, I just see that 1.0.7 has a deprecation notice, and claims to have been released on 2021-09-13, but that release does not exist on galaxy (https://github.com/ServiceNowITOM/servicenow-ansible/blob/devel/changelogs/changelog.yaml#L60)
19:00:54 <acozine> or removing it later
19:01:01 <acozine> but not removing it in 5
19:01:04 * jillr &
19:01:20 <felixfontein> bye to everyone who has to leave now :)
19:01:33 <acozine> thanks for driving, felixfontein !
19:01:36 <acozine> #unchair acozine
19:01:36 <zodbot> Current chairs: abadger1999 andersson007_[m] briantist cidrblock[m] cyberpear cybette dmsimard felixfontein gundalow jillr jtanner tadeboro
19:01:36 <dmsimard> felixfontein: does your answer change if we can work with them to get a new version out with the deprecation notices ?
19:01:49 <felixfontein> also release_summary is nothing which shows up in the Ansible changelog / porting guide, the correct section would be `deprecated_features`
19:02:00 <felixfontein> dmsimard: yes, I'm +1 then
19:02:17 <dmsimard> felixfontein: ok, I will try and report back next week.
19:02:22 <felixfontein> sounds good!
19:02:32 <cidrblock[m]> sorry folks, gotta run, tty soon
19:02:33 <felixfontein> do you want to #agree / #info something in this meeting?
19:02:38 <dmsimard> #action dmsimard to try and work with servicenow.servicenow to get a new version out with deprecation notices
19:02:52 <felixfontein> otherwise I'll switch to a tiny open floor
19:02:54 <dmsimard> ^ probably sufficient
19:02:57 <felixfontein> +1
19:03:03 <felixfontein> #topic Open Floor
19:03:12 <felixfontein> does anyone have something quick? otherwise I'll close in 1-2 minutes :)
19:03:31 <dmsimard> I have https://github.com/ansible-community/community-topics/issues/29 that I would really want to talk about :P
19:04:15 <felixfontein> let's talk about that next week
19:04:17 <felixfontein> :)
19:04:34 <dmsimard> In summary, by tuning just community.general and community.network, I was able to remove 2k+ files from the Ansible community package and make it install 10 seconds faster. If we agree with this approach, I would like to expand this work to all included collections ideally before Ansible 5
19:05:03 <felixfontein> short summary: there are a lot of legal problems waiting for us. (resp. we already have some of them right now, and doing that can unearth more dragons.)
19:05:30 <felixfontein> #endmeeting