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