15:00:19 <mkrizek> #startmeeting Ansible Core Public IRC Meeting
15:00:19 <zodbot> Meeting started Thu Jan 14 15:00:19 2021 UTC.
15:00:19 <zodbot> This meeting is logged and archived in a public location.
15:00:19 <zodbot> The chair is mkrizek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:19 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
15:00:35 <mkrizek> #info agenda https://github.com/ansible/community/issues/584
15:00:53 <mkrizek> #chair bcoca
15:00:53 <zodbot> Current chairs: bcoca mkrizek
15:03:15 <mkrizek> #topic hash_merge behavior
15:03:24 <mkrizek> Sounds like this did not get resolved last time. Anything to do regarding this today?
15:03:29 <felixfontein> hi!
15:03:40 <mkrizek> hello felixfontein
15:03:42 <bcoca> we were supposed to have items to vote on
15:03:49 <sdoran> \o
15:06:34 <mkrizek> any volunteers for preparing options to vote on for next meeting? ;-)
15:08:18 <bcoca> its realy 2 questions, revert current deprecation or not, after that is answered, several options on how to deal with the consequences for each answer
15:10:48 <mkrizek> Ok, do we have enough people today to vote on the former?
15:12:21 <sdoran> I'm not sure if we have enough folks present.
15:13:06 <felixfontein> enough folks, or enough volunteers? ;)
15:13:34 <felixfontein> (or both?)
15:14:08 <mkrizek> moving on then
15:14:11 <mkrizek> #topic Don't forget plugin deprecations after CLI init; include collection name in plugin deprecations
15:14:16 <mkrizek> #link https://github.com/ansible/ansible/pull/73058
15:14:49 <mkrizek> felixfontein: are you looking for reviewers or a discussion?
15:15:19 <bcoca> already talked aobu tthat one, need to change the approach, its on my list
15:15:38 <bcoca> aljso mixing things in the same issue
15:15:47 <felixfontein> bcoca hasn't been very clear about which approach to use
15:16:09 <bcoca> for the naming, we just need to pass fqcn in , instead of passing collection name everywhere
15:16:40 <bcoca> for the display, there are 2 diff conditions, on the setting and on the setting veihcle
15:17:19 <bcoca> and its not on load time, since that can happen even if plugin is not used, specifically conneciton plugins
15:17:45 <felixfontein> my combine two separate pieces of information so that the called function has to parse that information into two pieces?
15:17:51 <felixfontein> s/my/why/
15:18:09 <bcoca> no, you should not need 2 pieces
15:18:51 <bcoca> there is only 1 case where you need 2 pieces and  that is when fragment collection != plugin collection
15:19:12 <bcoca> and that is better to detect at source, vs passing the info around everywhere and uselessly in most cases
15:25:28 <mkrizek> felixfontein: does that sound good to you?
15:26:53 <felixfontein> IMO that would be a pretty invasive change, and not something that should be backported. This is a bugfix that should be backported.
15:27:12 <bcoca> well, you mixed 2 changes into one
15:27:24 <bcoca> and i would argue its more invasive to change the signatures
15:27:42 <bcoca> im saying lets separate them
15:27:47 <felixfontein> the argument is at the end and has a default value
15:27:56 <felixfontein> I can split it into two PRs if you prefer that
15:33:57 <mkrizek> ok, sounds like the details can be worked out in the separated PRs, bcoca says it's on his list to review
15:34:05 <mkrizek> #topic Always mention the name of the deprecated plugin in routing deprecation messages
15:34:10 <mkrizek> #link https://github.com/ansible/ansible/pull/73059
15:34:15 <mkrizek> felixfontein: you again :)
15:34:25 <felixfontein> surprise!
15:34:28 <bcoca> instead of or ''
15:34:34 <bcoca> just put it in the get
15:34:54 <felixfontein> bcoca: that won't work if someone uses `warning_text: ~`
15:35:25 <bcoca> that will be None
15:35:54 <felixfontein> yes. and get('warning_text', '') will then return None
15:36:14 <bcoca> i would put onus on people doing warning_text: ~
15:36:27 <bcoca> should validate it is a string
15:36:35 <felixfontein> true :) sanity tests also validate that.
15:36:42 <felixfontein> but so far, if someone put None, it was valid and worked
15:36:53 <felixfontein> (not valid in sense of sanity tests)
15:38:06 <bcoca> if it were not for people, software would work fine!
15:38:38 <felixfontein> same for broken capacitors
15:38:54 <mkrizek> 73059 looks good to me
15:39:21 <bcoca> w/o comments someone will probably refactor as i suggested
15:39:37 <shertel> Looks good to me too. +1 for adding a comment.
15:39:52 <felixfontein> the same was true for the original line 462 :)
15:41:52 <bcoca> not disputing that
15:42:01 <felixfontein> comment is there
15:42:30 <bcoca> +1
15:42:31 <felixfontein> the same is true if the user sets warning_text to false or 0 or anything else that's falsy
15:42:43 <mkrizek> +1
15:42:50 <bcoca> /me smacks  author
15:43:34 <mkrizek> felixfontein: anything else here before we move on to (your) next topic :-)
15:44:19 <felixfontein> mkrizek: for this topic, no. well, would be glad if someone could merge once CI passes ;)
15:44:28 <mkrizek> I'll do that
15:44:38 <felixfontein> thanks!
15:44:52 <mkrizek> #topic core team to make sure that for every change (after initial release) in a stable branch that adds things to the porting guide has a changelog fragment that has one of the porting guide sections
15:44:58 <mkrizek> #link https://github.com/ansible/community/issues/584#issuecomment-758884921
15:46:09 <felixfontein> I would be really glad if you could think of that in the future :)
15:47:28 <felixfontein> (and I don't want to pick on relrod's PRs here, it's just the first example I found)
15:49:38 <sivel> docs changes are purposefully one thing we don't include changelogs for. but I suppose we can talk about it
15:49:59 <bcoca> this would be 'doc change as clog'
15:50:08 <bcoca> would have to accompany the actual change
15:50:29 <bcoca> we tend to write those much later since most of the time the impact is not clear until someone hammers the change
15:50:50 <felixfontein> sivel: it's not about having a changelog entry for docs changes, it is that what caused the porting guide update after initial release should have a changelog entry with one of the 'porting guide' categories (breaking_changes, major_changes)
15:51:52 <felixfontein> so that updates to the porting guide after the initial release (GA) are documented in the changelog as well as breaking/major changes (or deprecations/removals, if appropriate)
15:52:32 <felixfontein> if they don't have that, people who already read the porting guide won't notice that it changed and that there is something to watch out for
15:52:49 <sivel> So to satisfy the tool we should add 2 categories? It was a CVE so it went in security_fixes
15:53:04 <sivel> I'm not really following what is being asked
15:53:07 <felixfontein> depends on the fix. not every security fix breaks things.
15:53:46 <bcoca> it just requires us being aware of porting guilde entry need when change is submitted, this is rare
15:53:59 <felixfontein> if it is a security fix and a breaking change, it should be in both categories. like `security_fixes:` `module - fixes CVE-xxx-xxx ...` and `breaking_changes:` `module - behavior is changed due to security fix in xxx cases`
15:54:11 <sivel> *shrug*
15:55:43 <felixfontein> I guess usually the porting guide isn't updated that often after a release, so this is indeed rare
15:56:01 <felixfontein> (and I don't mean editorial changes :) )
16:00:36 <shertel> I'll be mindful of it even though it should be infrequently necessary. It never occurred to me.
16:01:18 <felixfontein> shertel: thanks!
16:01:59 <felixfontein> besides that, I just came up with another solution: https://github.com/ansible/ansible/pull/73232
16:02:59 <felixfontein> (assuming that functionality still works)
16:03:17 <mkrizek> felixfontein: that won't work because notifications are turned off now
16:03:20 <sivel> bot notifications are disabled
16:04:10 <felixfontein> oh :(
16:09:55 <mkrizek> sounds like the consensus is that this situation is rare enough that we just need to be mindful of it
16:10:37 <mkrizek> and we're 10 minutes past the end of the meeting
16:10:46 <mkrizek> #endmeeting