15:00:18 <mkrizek> #startmeeting Ansible Core Public IRC Meeting
15:00:18 <zodbot> Meeting started Thu Dec 10 15:00:18 2020 UTC.
15:00:18 <zodbot> This meeting is logged and archived in a public location.
15:00:18 <zodbot> The chair is mkrizek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:18 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
15:00:24 <cyberpear> o/
15:00:32 <mkrizek> #info agenda https://github.com/ansible/community/issues/570
15:01:36 * shertel waves
15:01:48 <mkrizek> #chair shertel
15:01:48 <zodbot> Current chairs: mkrizek shertel
15:04:06 <mkrizek> #topic https://github.com/ansible/ansible/pull/72711
15:04:17 <mkrizek> ericzolf ^
15:04:32 <ericzolf> yes, my first meeting, let me know what you expect from me.
15:04:41 <felixfontein> oh, meeting time!
15:04:43 <cyberpear> https://github.com/ansible/ansible/pull/72711 should go to community.general, based on precedent, unless there's very good guidelines on what can go into core.  Otherwise, it's a great addition.
15:04:43 <felixfontein> \o/
15:05:31 <Shrews> is `a-1.9.rpm` supposed to sort before `a-1.09.rpm`?
15:06:13 <felixfontein> Shrews: I'd guess they'd count as equivalent, and thus the original order should be kept
15:06:23 <sivel> LooseVersion while consistent, isn't necessarily "correct"
15:06:30 <ericzolf> that's what the underlying library does, changing it would be difficult
15:06:32 <cyberpear> `rpmdev-vercmp` considers them equal
15:06:42 <ericzolf> what sivel wrote
15:07:01 <felixfontein> having an option to chose between different version comparisons would be useful
15:07:05 <Shrews> i figured as much, just wanted to clarify.
15:07:15 <sivel> I'd recommend allowing the underlying version comparison to be selected, like the `version` test
15:07:31 <sivel> then it could be StrictVersion, LooseVersion, or SemanticVersion
15:08:29 <Shrews> i also think it should probably go to `c.g`
15:08:31 <ericzolf> can do, doesn't sound a big deal to implement.
15:08:34 <sivel> would be better if the upstream `sort` could accept a test
15:08:43 <mkrizek> ericzolf: yes so like cyberpear already mentioned, generally new plugins go to collections, probably `community.general` in this case. I guess the first question is: does anyone think we should include `version_sort` into core? The implementation details can be then decided in a Pr, either in ansible/ansible or specific collection
15:09:01 <sivel> mkrizek: I'm not overly convinced it needs to live in core
15:10:11 <cyberpear> I'd be in favor of putting it into core, but only if first there are guidelines on what kind of filters can be directly in core... I've been shot down in the past with filters that would be very useful in core.
15:11:00 <Shrews> ^ which is also why i prefer for that to go to `c.g`
15:11:01 <sivel> the guidelines are typically core team agreement
15:11:43 <ericzolf> As an occasional developer, it would be cool to have guidelines though, it would have spared me a bit of time.
15:12:35 <sivel> I'm not sure it'll ever be possible to distill that down, As far as I am concerned, it was the correct thing to do to open the PR as you did
15:14:34 <Shrews> yep, it's worth having the discussion, even if the end result is a bit more work
15:14:46 <ericzolf> Just saying, it might rebuke newcomers, but I accept the decision. The code itself isn't so much the issue but the test framework seems different though.
15:16:42 <ericzolf> That's it then?
15:16:58 <mkrizek> ericzolf: what would you suggest to make the process better?
15:17:51 <ericzolf> 1. have a way to check before hand the right place to discuss where to plug the PR. Simply ask on ansible-devel?
15:18:28 <shertel> it may be worth having some kind of note in the contributor guide that not many new plugins are being accepted into ansible/ansible, and the feature idea should be brought to a meeting first
15:19:13 <mkrizek> or maybe even a note in github PR template?
15:19:26 <ericzolf> 2. improve the documentation for the test-framework(s) - I only did pattern matching but couldn't find a documentation (same thing in community.general)
15:19:45 <ericzolf> mkrizek, I would 2nd this
15:20:41 <ericzolf> before the reviewer gives "homework" to the author, so to say
15:21:03 <shertel> +1
15:21:37 <cyberpear> the most recent code contribution I tried to do was an enhancement to the regex_search filter... originally, core said "great!" then it was decided it'd be better to be a separate filter, then once I did that work, it was said, please instead go to c.g since it's now a separate new filter... which I still haven't had the motivation to actually do; I just carry the filter in each role that uses it now.
15:22:44 <mkrizek> #action mkrizek to discuss with the community team about better communicating a process of accepting new plugins into core
15:24:17 <mkrizek> anyway sounds like more people are in favor of `version_sort` going into `community.general` collection
15:26:18 <ericzolf> fair enough, I'll create a new PR over there.
15:26:25 <mkrizek> #agreed `version_sort` to go to `community.general`
15:26:56 <mkrizek> ericzolf: thank you and sorry for the confusion, do you have anything else for this?
15:27:13 <ericzolf> Nope, interesting experience, thanks.
15:27:29 <mkrizek> #topic Open floor
15:27:40 <mkrizek> Does anyone have anything else to discuss?
15:28:35 <mkrizek> If not I am going to end the meeting in a few minutes.
15:28:35 <felixfontein> https://github.com/ansible/ansible/pull/72625 maybe?
15:28:57 <mkrizek> felixfontein: go ahead
15:29:09 <felixfontein> I think it's a useful test, especially now that collections start preparing for a new major release (like community.general and community.network)
15:29:56 <felixfontein> the PR adds validation of the removal and deprecation versions and dates in meta/runtime.yml
15:30:23 <felixfontein> similar to the tests that validate deprecation versions for modules
15:33:48 <shertel> seems useful, just needs a review probably?
15:34:46 <mkrizek> yep, agreed
15:35:12 <mkrizek> felixfontein: did you have anything specific to discuss about the PR?
15:35:53 <shertel> I can add to my queue to review tomorrow or early next week
15:36:06 <mkrizek> thanks shertel
15:37:07 <felixfontein> mkrizek: mostly "does anyone else than me wants this?" ;)
15:37:13 <felixfontein> shertel: thanks a lot!!!
15:37:45 <shertel> np
15:39:39 <mkrizek> ok, anything else?
15:39:41 <ericzolf> is discussing an idea a valid topic for this round (before I create an issue)?
15:40:01 <mkrizek> sure
15:40:06 <ericzolf> I recently stumbled about the fact that `ignore_errors` can't be evaluated on the basis of the task's result (aka registered variable), would it be a valid idea to have instead/additionally an `ignored_when` handled very similarly to `changed_when` and `failed_when`?
15:41:22 <sivel> Why not just use `failed_when` in that scenario?
15:42:03 <ericzolf> because I still want to be made aware in the summary that something went wrong, in the sense ignored == warning
15:44:00 <ericzolf> and long term, ignore_errors could be thrown away, giving a more consistent user interface
15:44:47 <sivel> I might be more apt to accept some module(action) in the vein of `debug` and `fail` that can produces a warning, and could be used in a block/rescue with warn+when
15:46:40 <sivel> But my feeling is that we would probably not accept ignored_when
15:47:08 <ericzolf> block + rescue don't make the playbook nicer / easier to read but yeah, I asked to avoid unnecessary work for everybody :-)
15:48:45 <ericzolf> OK, then, thanks and bye!
15:55:25 <mkrizek> ok, sounds like that's it for today, thanks all!
15:55:28 <mkrizek> #endmeeting