19:12:13 <bcoca> #startmeeting ansible core public irc meeting
19:12:13 <zodbot> Meeting started Tue Jul 23 19:12:13 2019 UTC.
19:12:13 <zodbot> This meeting is logged and archived in a public location.
19:12:13 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:12:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:12:13 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
19:12:20 <sdoran> \o
19:12:30 <bcoca> #topic https://github.com/ansible/ansible/pull/58646
19:12:32 <jtanner> o/
19:12:37 <jillr> o/
19:12:44 <bcoca> ^ acozine brought up last meeting , but we had no quorum
19:13:03 <bcoca> previous vote was to always show 'type: str' by default , even when abset (cause its the actual implied default)
19:13:24 <bcoca> but acozine worried this will show 'explicitly incorrect' docs for many modules (aroun 1400, 4000 options are mismatched)
19:13:43 <bcoca> and requested we vote to add the check, but hold off on 'default display to str' until modules were converted
19:13:49 <bcoca> s/converted/corrected/
19:14:01 <bcoca> we had 4/0 last meeting, but need more peopel to weigh in
19:14:10 <acozine> o/
19:14:28 <bcoca> ^ feel free to update/correct
19:14:33 <acozine> I still feel that incomplete docs are better than inaccurate docs
19:14:53 <acozine> I'd rather not display the type than display the wrong type
19:15:27 <jtanner> "When the default argument type was changed to str, we did not change the behavior of ansible-doc to display type: str if no type is specified in the module documentation. Rather than requiring every string parameter be documented as such, we should insert type: str if it isn't present for a given parameter i"
19:15:30 <jtanner> seems logical
19:16:26 <bcoca> giving a fewmins for people to catch up, but starting vote
19:16:49 <bcoca> +1 to existing PR changing checks, but removing the default display part
19:17:01 <acozine> jtanner: it is logical, but unfortunately "no type is specified in docs" != "type is actually a string"
19:17:40 <jillr> +1 to checking, but not displaying any default until modules with missing docs are updated
19:20:12 <jtanner> jillr is probably right, i just don't think that they'll all get updated
19:20:42 <bcoca> that is my concern also, but matt clay has assured me people do go over ignore.txt and udpate modules to fix the issues
19:20:59 <nitzmahone> Yep, +1 to the changes, but don't display that value until we're sure it's accurate
19:21:05 <bcoca> i would love a 'warning' on ci that 'you changes to module A are good, but it has these minor outstanding issues : '
19:21:17 <bcoca> ^ but that is a lot to ask
19:21:23 <nitzmahone> "hey $contributor,  since you're in the neighborhood..."
19:21:28 <bcoca> exactly
19:21:56 <jborean93> Could be problematic for the Windows modules that haven’t been converted to the new arg spec
19:22:02 <bcoca> makign it an error seems like punishing contributors (unless we can match they are the ones that created the issue)
19:22:20 <bcoca> jborean93: agreed, and i would have voted otherwise if i had realized that was still an issue
19:22:38 <bcoca> but this vote should leave us with a check and a 'long list' of todo in fixing modules
19:22:43 <jborean93> Plus action plugins don’t have an arg spec
19:22:46 <nitzmahone> Yeah, adding the windows modules that haven't been updated to ignore would make sense
19:22:54 <bcoca> jborean93: that is what 'controller side argspec' is for
19:22:59 <bcoca> any day now ...
19:23:12 <jborean93> I thought that was implemented in 2.4 :P
19:24:00 <bcoca> s/2.4/since 1.4/
19:24:32 <jborean93> I think we could be smarter and only error if type != string on modules we can validate the arg spec for
19:25:00 <jborean93> Currently validate modules will just skip the validation if it can’t read the arg spec (I.e. old PowerShell type)
19:25:46 <bcoca> i think that is how the previous and new check would still work
19:26:15 <bcoca> i basically merged 3 checks into one simpler one (args mismatch docs)
19:26:28 <bcoca> didnt do anything about general validate-modules execution rules
19:28:27 <bcoca> k, so factoring in last meeting i think i can say +6/0 .. going to consider it 'passing'
19:28:38 <bcoca> #topic open floor
19:32:52 <bcoca> k, since nothing has com up in 5m, ending meeting
19:32:56 <bcoca> #endmeeting