19:01:02 <felixfontein> #startmeeting Ansible Community Meeting
19:01:02 <zodbot> Meeting started Wed Dec 16 19:01:02 2020 UTC.
19:01:02 <zodbot> This meeting is logged and archived in a public location.
19:01:02 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:02 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:01:07 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping!
19:01:10 <dmsimard> \o/
19:01:13 <felixfontein> #topic agenda https://github.com/ansible/community/issues/539
19:01:19 <abadger1999> Good day
19:01:28 <daniel-wtd> o/
19:01:55 * dericcrago waves
19:01:58 <cybette> o/
19:02:41 <resmo> o/
19:02:47 <felixfontein> #chair dmsimard abadger1999 daniel-wtd dericcrago cybette resmo
19:02:47 <zodbot> Current chairs: abadger1999 cybette daniel-wtd dericcrago dmsimard felixfontein resmo
19:02:50 * gundalow waves
19:03:27 <felixfontein> #chair gundalow
19:03:27 <zodbot> Current chairs: abadger1999 cybette daniel-wtd dericcrago dmsimard felixfontein gundalow resmo
19:03:33 <felixfontein> #topic Announcements
19:03:38 <felixfontein> #info ansible-base 2.10.4, Ansible 2.9.16 and Ansible 2.8.18 have been released
19:03:41 <felixfontein> #info The Bullhorn 16 has been released: https://mailchi.mp/redhat/the-bullhorn-16
19:05:27 <dmsimard> any other announcements ?
19:05:52 <felixfontein> not from my side :)
19:05:56 <gundalow> AZP, one moment
19:06:03 <felixfontein> ah yes, good point
19:06:12 <gundalow> #info Ansible PR review day is tomorrow https://github.com/ansible/community/issues/407
19:06:15 <felixfontein> gundalow has been busy :)
19:06:36 <dmsimard> ah, yes, PR day
19:06:44 <gundalow> #info Move from Shippable to Azure Pipelines (CI) is going well https://github.com/ansible-collections/overview/issues/124
19:07:10 <gundalow> Is there a meeting next week?
19:07:19 <gundalow> I don't think so
19:07:23 <resmo> no PR day for me, meeting collision
19:07:31 <felixfontein> I'm around in any case :)
19:07:34 <abadger1999> #info A procedure for submitting and  reviewing new collections was published in the bullhorn.  If you have a collection for ansible-3.0.0, please read https://mailchi.mp/redhat/the-bullhorn-16
19:07:34 <gundalow> resmo: must be a long meeting :P
19:07:37 <felixfontein> or I'm probably around
19:08:18 <gundalow> #info No IRC meetings till Jan after this wek
19:08:25 <gundalow> #undo
19:08:25 <zodbot> Removing item from minutes: INFO by gundalow at 19:08:18 : No IRC meetings till Jan after this wek
19:08:32 <gundalow> #info No IRC meetings till Jan 2021
19:08:37 <gundalow> Nothing else from me
19:09:56 <felixfontein> abadger1999: do you want to chair the discussions on the 3.0.0 collection guidelines (the remaining questions from last week)?
19:09:58 <dericcrago> I've started migrating fortios out of `c.network` and into `c.fortios`
19:10:04 <resmo> abadger1999, me working on a new collection for ansible 3.0.0
19:10:07 <felixfontein> dericcrago: awesome! I was about to ask :)
19:10:20 <abadger1999> felixfontein: sure
19:10:47 <abadger1999> resmo: Cool.  You know you need to get it submitted as early as possible?  (probably beginning of January)?
19:11:03 <abadger1999> #topic Some changes to the collection guidelines
19:11:16 <resmo> abadger1999, doable, I know, the earlier the better...
19:11:18 <abadger1999> So we approved a checklist last week but some problems were raised after the meeting.
19:12:06 <abadger1999> Looks like a couple changes were made that weren't approved.
19:12:20 <abadger1999> Easier one first: https://github.com/ansible-collections/overview/pull/137
19:12:20 <github-linkbot> https://github.com/ansible-collections/overview/pull/137 | open, created 2020-12-09T21:08:35Z by abadger: Need approval of the CI changes
19:12:58 <abadger1999> There are two changes to running CI that weren't approved.
19:13:04 <abadger1999> I'll take them one at a time
19:13:38 <abadger1999> #topic Checklist: running CI against the version of ansible/ansible-base that the collection supports
19:13:51 <abadger1999> PROPOSAL: "You MUST run CI against all versions of ``ansible-base``/``ansible-core`` that the collection supports."
19:14:07 <dmsimard> I'm -1 on the phrasing of "all versions"
19:14:17 <abadger1999> <nod>
19:14:22 <abadger1999> What would you suggest?
19:14:28 <felixfontein> the formulation is a bit imprecise. it shouldn't say "all" versions, but something like "the latest 'major' versions of the ansible/ansible-base/ansible-core" - namely the corresponding stable-xxx branches
19:14:37 <dmsimard> what felixfontein said ^
19:14:45 <gundalow> felixfontein: yup, that's what I meant, thank you for suggesting better wording
19:14:50 <felixfontein> no collection is testing against ansible-base 2.10.0, 2.10.1, 2.10.2, 2.10.3, 2.10.4
19:15:01 <dmsimard> felixfontein: get out of my head :p
19:15:05 <felixfontein> dmsimard: :P
19:15:54 <felixfontein> gundalow: not sure whether that wording is much better though... some word-smithing won't hurt :)
19:16:10 <abadger1999> PROPOSAL: "You MUST run CI against each of the major versions  of``ansible-base``/``ansible-core`` that the collection supports. (Usually the head of the stable-xxx branches for ansible-base or the latest ansible major release tarballs"
19:16:16 <gundalow> +1
19:16:21 <dericcrago> is it latest major or minor versions and is that going to be different between now and "future"?
19:16:47 * resmo afk -> kids bed
19:16:49 <gundalow> 2.9, 2.10 and 2.11 are all major versions
19:16:51 <geerlingguy> sorry can't be on today, dealing with health insurance :P
19:16:53 <abadger1999> oops, ansible-base/core... so I don't need to mention ansible tarballs.
19:17:03 <felixfontein> how about adding quotes to 'major'? so people don't think they have to test against ansible-1, ansible-2, ...? ;)
19:17:04 <dmsimard> geerlingguy: good luck
19:17:04 <abadger1999> PROPOSAL: "You MUST run CI against each of the major versions  of``ansible-base``/``ansible-core`` that the collection supports. (Usually the head of the stable-xxx branches.)"
19:17:16 <gundalow> +1
19:17:22 <felixfontein> geerlingguy: good luck indeed!
19:17:29 <felixfontein> +1 for that proposal
19:17:29 <abadger1999> PROPOSAL: "You MUST run CI against each of the "major versions" (2.10, 2.11, 2.12, etc)  of``ansible-base``/``ansible-core`` that the collection supports. (Usually the head of the stable-xxx branches.)"
19:17:29 <geerlingguy> dmsimard: I've been putting off this call forever and ever. Already been 35 minutes and been through two phone systems, have not yet reached a human :P
19:17:37 <dmsimard> I wonder if "each of" is necessary
19:17:50 <dmsimard> but that's me nitpicking
19:17:52 <dmsimard> otherwise +1
19:18:34 <abadger1999> +1 from me
19:18:43 <gundalow> #chair
19:18:43 <zodbot> Current chairs: abadger1999 cybette daniel-wtd dericcrago dmsimard felixfontein gundalow resmo
19:19:01 <dericcrago> what would it say once 4.0 is out for example?
19:19:05 <felixfontein> #chair geerlingguy
19:19:05 <zodbot> Current chairs: abadger1999 cybette daniel-wtd dericcrago dmsimard felixfontein geerlingguy gundalow resmo
19:19:10 <gundalow> dericcrago: that's still a major version
19:19:12 <gundalow> PROPOSAL: "You MUST run CI against each of the "major versions" (2.10, 2.11, 2.12, etc)  of``ansible-base``/``ansible-core`` that the collection supports. (Usually the head of the stable-xxx branches.)"
19:19:23 <felixfontein> +1
19:19:34 <abadger1999> dericcrago: that would depend on what ansible-core's versioning scheme is.  so I say we defer until ansible-core does that.
19:19:50 <felixfontein> 4.0.0 sounds more like ansible, not ansible-base/-core
19:20:19 <gundalow> 2.10 is a major version, 4 is also a major version (once we move to semver)
19:20:34 <abadger1999> (since ansible-core could go to semver... or they might just bump the first number but continue to have their current versioning and release practices.... we don't know what they would do yet)
19:20:45 <dericcrago> gundalow - exactly, that's the part that I think could be confusing
19:21:04 <gundalow> When that happens we will review the checklist
19:21:04 <abadger1999> This guideline is talking abo9ut ansible-core and not ansible.
19:21:15 <abadger1999> (in case that wasn't understood)
19:21:37 <dericcrago> if it's 2.x then it's the `2.#` that is major version, if it's >2, then it's `#` on it's onw that's major version
19:21:46 <dericcrago> it wouldn't say 2.12, 3.0, 3.1, right?
19:21:52 <abadger1999> dericcrago: we don't know
19:21:55 <dericcrago> ok
19:22:08 <abadger1999> because we don't know how ansible-core would version the 3.x series.
19:22:31 <felixfontein> I'm not even sure they really know yet :)
19:22:34 <abadger1999> They might bump from 2.x to 3.x but keep the same version numbering scheme they do now.  Or they might switch to semver or something else.
19:22:36 <dericcrago> ok, you can disregard my rambling then :)
19:23:16 <dericcrago> I'm +1 for the proposal :)
19:23:25 <felixfontein> +1
19:23:29 <abadger1999> Okay :-)  Anyone else want to vote?
19:23:46 <dmsimard> also +1 from me
19:24:28 <abadger1999> #info Checklist change PASSED [+5, 0, -0]: You MUST run CI against each of the "major versions" (2.10, 2.11, 2.12, etc)  of``ansible-base``/``ansible-core`` that the collection supports. (Usually the head of the stable-xxx branches.)
19:25:09 <abadger1999> #topic Checklist change about running CI against every commit
19:25:59 <abadger1999> This also was not approved expictly and was objected to as being onerous when the workflow isn't similar to the ansible-core commit workflow
19:26:00 <felixfontein> that's kind of hard, since I'm not sure how to actually achieve this
19:26:17 <abadger1999> So we'd like to strike it and replace it with this:
19:26:36 <felixfontein> it's not even true for the ansible-core commit workflow (at least if you count commits in PRs)
19:26:40 <abadger1999> PROPOSAL: [*] All CI tests MUST run against every pull request (last pushed commit to the repository) and MUST pass before merge with the exception when something outside of maintainers control breaks them.    [*] All CI tests MUST pass for the commit that releases the collection.
19:26:51 <abadger1999> felixfontein: yeah, I agree.
19:27:09 <gundalow> That's much better than my original wording
19:27:10 <gundalow> +1
19:27:30 <dmsimard> makes sense to me, /me looks original wording
19:27:32 <abadger1999> tadeboro: If you are around, Does the above PROPOSAL work for you?  (If you're resting, feeling free to ignore me)
19:27:54 <felixfontein> I think I already violated this several times in community.general, when several things in CI broke simultaneously, and I created different PRs for each problem - the first one merged will have failing tests (because the others are still open)
19:28:23 <gundalow> yup, likewise I've violated this
19:28:24 <dericcrago> to me at a minimum it seems like it should run regularly against the tagged versions of the collection and the supported major versions of `ansible-base`/`ansible-core`
19:28:48 <abadger1999> dericcrago: that rule is encoded in a different item, I think.
19:29:37 <abadger1999> dericcrago: "All CI tests MUST run regularly [...] at least once a week [...]"
19:29:40 <felixfontein> I don't think CI is ever ran against existing tagged versions of the collection once they have been released. (only if no new commits have been added to `main`.)
19:30:18 <dmsimard> How about simplifying it a bit ? "All CI tests MUST run against every pull request and SHOULD pass before merge" and we keep "All CI tests MUST pass for the commit that releases the collection"
19:30:26 <abadger1999> felixfontein: Do we want to separately discuss removing that other requirement, then?
19:30:49 <gundalow> Once a collection is released if (say) ansible-base changes and causes the previously released collection to be broken we wouldn't know
19:31:11 <felixfontein> abadger1999: no, the requirement we already have is fine, I think dericcrago's idea covers a lot more than what we have
19:31:14 <dericcrago> gundalow - that's what I was thinking
19:31:40 <felixfontein> abadger1999: and I don't think that extra part is a good idea, since we can't really fix old tagged releases once they have been tagged, so running CI against them is somewhat pointless
19:31:54 <abadger1999> felixfontein: <nod> makes sense
19:32:35 <abadger1999> So it's more like "run against HEAD of release branches" rather than "run against release tags"
19:33:05 <felixfontein> yes. though many collections (at least in community land) have no release branch, they only have `main`
19:33:09 <abadger1999> <nod>
19:33:19 <felixfontein> we have no nightly CI for stable-x branches in c.g and c.n btw
19:33:30 <dericcrago> felixfontein - I we could run into a scenario where the latest tests are passing, but the latest tagged release isn't and then we go to include it
19:33:41 <dericcrago> I *think we
19:34:10 <abadger1999> Maybe that CI run is something to add and if we find it's hard to do, we should revisit the requirement for others.
19:34:35 <felixfontein> dericcrago: it would be nice to have that, but a) it binds a lot of CI resources, and b) no collection is doing that right now, and we can't require everyone to do something that nobody does right now
19:35:26 <felixfontein> I'm not even sure how many people actually regularly check the nightly CI result of their collection for the nightly runs of the `main` branch
19:36:21 <dmsimard> once the collection is released in an ansible package there's no way back
19:36:37 <dericcrago> ok, maybe it's a different discussion, but I think we need something for when we're creating builds that verifies the latest tagged version still works with what we're building
19:36:55 <dmsimard> pretend we have 2.10.4 as the latest version, if the version of a collection included in 2.10.3 no longer works with the version of ansible-base that gets installed there's little we can do about it
19:37:03 <dmsimard> need to roll forward and include the fix in a future release
19:37:35 <dmsimard> it's on us to do a certain amount of testing prior to releasing to prevent obvious issues but we're not going to catch everything
19:38:24 <dmsimard> ideally we would re-run all of the collections' tests right before build/packaging/releasing but as the number of collections grow, it might become unrealistic
19:38:29 <abadger1999> <nod>
19:39:46 <abadger1999> So, about the section this proposal addresses..  with dmsimard's suggestion, it becomes:
19:40:01 <abadger1999> PROPOSAL: [*] All CI tests MUST run against every pull request (last pushed commit to the repository) and SHOULD pass before merge.    [*] All CI tests MUST pass for the commit that releases the collection.
19:40:32 <abadger1999> Any other changes to that or should we vote on it?
19:41:28 <felixfontein> sounds good to me
19:41:44 <gundalow> what's `(last pushed commit to the repository)` mean wrt PR?
19:42:11 <abadger1999> I interpret it to be the HEAD of the PR.
19:42:21 <abadger1999> better wording suggestion?
19:42:31 <gundalow> Is it needed, does it add anything?
19:42:38 <dmsimard> It's somewhat implied
19:42:41 <felixfontein> I think it means the merged result, which can be one commit (in case of squash), or multiple commits (in case of merge or rebase)
19:43:00 <dmsimard> I think the intent is to make sure that the PR should not against outdated HEAD ?
19:43:05 <felixfontein> tadeboro said they don't squash, and could have intermediate commits that fail CI
19:43:32 <abadger1999> "the final state of the PR"?  "the PR's final commit before merging"?
19:43:39 <dmsimard> oh
19:43:47 <dmsimard> you mean the last commit in the PR
19:43:51 <abadger1999> yeah.
19:43:54 <dmsimard> like it's ok for a commit to fail so long as the last one passes
19:43:58 <abadger1999> yep.
19:43:58 <felixfontein> yep
19:44:14 <gundalow> ok, so we should say latest commit then
19:44:25 <dmsimard> I think that's included in "SHOULD pass before merge"
19:44:37 <dmsimard> not sure whether the distinction is necessary
19:44:56 <gundalow> PROPOSAL: [*] All CI tests MUST run against every pull request and SHOULD pass before merge.    [*] All CI tests MUST pass for the commit that releases the collection.
19:45:02 <gundalow> (ie remove ` (last pushed commit to the repository) `)
19:45:23 <dmsimard> +1
19:45:34 <felixfontein> +1
19:45:37 <dericcrago> +1
19:45:55 <abadger1999> +1
19:46:19 <gundalow> +1
19:46:24 <dmsimard> anyone else? ^
19:46:25 <dmsimard> #chair
19:46:25 <zodbot> Current chairs: abadger1999 cybette daniel-wtd dericcrago dmsimard felixfontein geerlingguy gundalow resmo
19:47:57 <abadger1999> #info APPROVED [+5, 0, -0] Replace "All CI tests MUST run against every PR & commit to the repo." with "[*] All CI tests MUST run against every pull request and SHOULD pass before merge.    [*] All CI tests MUST pass for the commit that releases the collection."
19:48:40 <abadger1999> #topic CoC change to not require Ansible's CoC: https://github.com/ansible-collections/overview/pull/136/files
19:48:43 <abadger1999> This one is harder.
19:48:53 <abadger1999> jillr: if you're around, we're going to discuss the CoC requirement
19:49:43 <abadger1999> Some collections will have their own CoC already or their company's legal teams or other open source project that they're a part of might mandate specific language in a CoC.
19:50:09 <gundalow> cybette:
19:50:25 <abadger1999> Additionally, it feels a little heavy handed to me to mandate that our CoC is the only right one; similar to how we're working to allow other open source licenses.
19:50:50 <abadger1999> jillr, samccann, and I talked after last week's meeting and came up with a different policy.
19:51:06 <dmsimard> I think the important part is to have a CoC -- failing that, defaulting to the Ansible CoC sounds acceptable to me
19:51:39 <felixfontein> we should definitely have that fallback
19:51:58 <abadger1999> As well as some thoughts on where we want the CoC requirement to go i nthe future
19:52:08 <abadger1999> Here's the summary of the discussion:  https://hackmd.io/HqDFvkRXQBq28urikxtlCg?both
19:53:30 <abadger1999> I think the important points for an initial policy are:
19:53:34 <abadger1999> MUST have a CoC
19:53:42 <abadger1999> MUST be compatible with the Ansible CoC
19:54:05 <felixfontein> +1 for both!
19:54:18 <abadger1999> Rcommend that projects use our CoC if they don't have a CoC they consider is better
19:54:35 <felixfontein> +1 for that too
19:55:26 <abadger1999> Have a procedure to evaluate the CoCs that collections use and raise objections  (suggested: Have the Diversity and Inclusion working group review CoCs)
19:56:29 <abadger1999> I think if we have those four points, it tides us over until the D&I working group can get a handle on the problem (criteria for what should be in a good CoC and a list of approved standard CoCs, similar to present-day good opensource license lists)
19:56:40 <felixfontein> it would be great if the D&I WG could help with this, I don't have any experience with evaluating CoCs...
19:56:53 <abadger1999> <nod> I agree
19:57:28 <daniel-wtd> abadger1999: this list would be nice
19:57:35 <daniel-wtd> so one has some examples what can be used
19:58:01 <abadger1999> So maybe for the last one: "the Diversity and Inclusion working group may evaluate all CoCs and object to a collection's inclusion based on the CoCs contents"
19:58:34 <abadger1999> daniel-wtd: yeah.  I quite agree with that.
19:58:41 <daniel-wtd> +and recommend changes
19:58:44 <cybette> this would be a good item to add to the D&I WG meeting agenda for Jan 7
19:58:53 <dmsimard> cybette: +1
19:59:03 <cybette> I'll do that
19:59:24 <cybette> #action cybette to add CoC discussion to D&I WG meeting agenda
19:59:27 <gundalow> cybette: thanks :)
20:00:16 <abadger1999> yay :-)
20:00:34 <dmsimard> formal vote on a proposal ?
20:01:12 <abadger1999> PROPOSAL: Replace the current CoC requirement with the following four points:
20:01:19 <abadger1999> * Collections MUST have a CoC
20:01:31 <abadger1999> * The collection's CoC must be compatible with the Ansible CoC
20:02:09 <abadger1999> * Collections should consider using the Ansible CoC if they do not have a CoC that they consider better
20:02:21 <abadger1999> * the Diversity and Inclusion working group may evaluate all CoCs and object to a collection's inclusion based on the CoCs contents
20:02:29 <felixfontein> +1
20:02:31 <abadger1999> +1
20:02:42 <daniel-wtd> +1
20:02:43 <dmsimard> +1
20:02:47 <cybette> +1
20:02:57 <dericcrago> +1
20:03:16 <gundalow> +1
20:03:37 <abadger1999> #chair
20:03:37 <zodbot> Current chairs: abadger1999 cybette daniel-wtd dericcrago dmsimard felixfontein geerlingguy gundalow resmo
20:03:55 <abadger1999> Anyone else want to vote on the changes to the CoC guidelines?
20:04:28 <abadger1999> Okay
20:05:12 <abadger1999> #info APPROVED [+7, 0, -1] Replace current CoC requirement with one that is more flexible and has D&I review.
20:05:24 <abadger1999> felixfontein: okay, that's all I have for checklist updates.
20:05:41 <felixfontein> do we want to look at https://github.com/ansible-collections/overview/pull/139 as well?
20:05:42 <github-linkbot> https://github.com/ansible-collections/overview/pull/139 | open, created 2020-12-13T01:05:11Z by russoz: List of unacceptable values for new entries in ignore files
20:05:52 <abadger1999> #action abadger1999 to update and merge the PRs impelemnting the approved checklist changes.
20:05:54 <felixfontein> it's a list of entries that shouldn't be in ignore.txt files by russoz
20:06:12 <felixfontein> also, should we vote (again) on the complete checklist?
20:08:16 <abadger1999> I think voting o nthe complete checklist was a one-time thing since it had originally grown organically.
20:08:25 <felixfontein> ok, fine for me :)
20:08:47 <abadger1999> If we don't have anything more pressing, I am okay discussing the list of things that shouldn't be in ignore.txt.
20:08:54 <abadger1999> How was this list derived?
20:08:58 <abadger1999> russoz: Are you around?
20:09:33 <felixfontein> the only other topic I'm aware of is inclusion of new content in community.general / community.network, but it has been some weeks ago that we discussed it and several interested people aren't around
20:09:34 <gundalow> I think it's very early for russoz
20:10:10 <russoz> howdy guys, just got back from dropping kid at school
20:10:17 <abadger1999> Hi :-)
20:10:44 <felixfontein> I'm not sure how the list was compiled, but the entries look very sensible - they are easy to fix and there's no good excuse to have them around
20:11:07 <russoz> the list was derived from the work I've done cleaning similar entries from those files
20:11:21 <russoz> felixfontein I couldn't have said it better
20:11:28 <abadger1999> <nod>
20:12:15 <gundalow> russoz: List looks great (and thanks again for reducing ignore.tx)
20:12:36 <russoz> truth be said, I still think in the long run we should generate documentation straight from the `argument_spec` blob, but hey, can of worms alert there :-)
20:12:37 <dmsimard> do we know if any of the currently included collections are infringing on that ?
20:12:38 <gundalow> I'm personally a little confused by `for the sake of documentation completeness and accuracy`
20:12:43 <abadger1999> I worry that the list of MUST NOT's includes warnings that are in the top spots currently.
20:13:07 <abadger1999> But if you think that they are all things which have no excuse to be around, that does seem like the proper criteria.
20:13:29 <russoz> gundalow thanks, and maybe my wording wasn't the best, feel free to adjust as you see fit.
20:13:38 <felixfontein> abadger1999: they are mainly there because it is not always trivial to fix them for existing collections, if you're not familiar with all the modules in it. so it's mostly a problem for community.general and community.network
20:13:56 <russoz> abadger1999 As I understood it, that was for NEW modules right?
20:14:58 <russoz> felixfontein abadger1999: the top offending one today is list without elements - many should be trivial (string), but some are quite convoluted
20:14:59 <felixfontein> it's for new collections, mostly, not for new modules
20:15:35 <felixfontein> russoz: yes, `elements` is one of the hardest. the problem is usually that determining whether string (or something else) is ok requires to understand the module, or even the API it uses
20:15:46 <russoz> exactly
20:16:31 <abadger1999> russoz: yeah, unless there was a compelling reason, we'd grandfather in current collections.... maybe require them to prioritize PRs but probably not kick them out
20:17:00 <abadger1999> Perhaps list-without-elements should be left off the list then?
20:17:11 <russoz> gundalow the idea behind that phrasing is that those validations in the list they are related to keeping the ``DOCUMENTATION`` blob in sync with ``argument_spec``
20:18:28 <russoz> abadger1999 off the list for new collections? IMHO we should try and enforce it in new collections so we don't replicate the current state of c.g. in them
20:19:01 <jillr> sorry I was away, chiming in late but for posterity I'm +1 the 4 points about CoCs
20:19:11 <abadger1999> jillr: Thanks!
20:19:12 <felixfontein> #chair jillr russoz
20:19:12 <zodbot> Current chairs: abadger1999 cybette daniel-wtd dericcrago dmsimard felixfontein geerlingguy gundalow jillr resmo russoz
20:19:44 <abadger1999> #info jillr also approved the 4-point CoC criteria update.
20:20:24 <felixfontein> I'm happy to accept the list as-is, as long as we have some wiggle room especially for content originating in ansible/ansible
20:20:36 <abadger1999> russoz: It feels like, if something is hard for us to get right, it might not be a good idea to force it on  others.
20:21:09 <abadger1999> felixfontein: Other than grandfathering, I don't think there should be much (if any) wiggle room with this list.
20:21:18 <felixfontein> abadger1999: it should mostly be hard for catch-all collections like c.g and c.n
20:21:29 <felixfontein> or for large collections that have way too few maintainers
20:21:34 <russoz> felixfontein agree - in my previous statement I was thinking of new as in shiny brand new collections, not refactoring of existing things
20:21:42 <abadger1999> to me, the purpose of this particular list would be "any time you see this, it's a 100% genuine error that must be fixed"
20:21:44 <felixfontein> but including such new ones into ansible is probably something we don't want to do anyway :)
20:22:06 <gundalow> Doesn't the existing checklist allow us humans to have final say?
20:22:43 <russoz> abadger1999 I dont believe that is something hard to get right, we probably have that from: a) a time when this wasn't checked, so it is plain legacy and b) laziness
20:22:47 <gundalow> ie if someone migrates a load of content from community.general to a new dedicated collection I wouldn't block that on them fixing all the ignore.txt entries
20:23:32 <russoz> gundalow I second that - refactoring is a different beast
20:23:48 <abadger1999> gundalow: yeah.... to me the current guideline is "You SHOULD not have ignored test entries.  A reviewer can manually evaluate and approve your collection if they deem an ignored entry to be valid.
20:23:57 <gundalow> +1
20:24:30 <abadger1999> And then adding a list would be "We don't believe these entries are ever valid in an ignore file.  They must be fixed before approval"
20:24:55 <gundalow> That sounds good to me
20:24:55 <russoz> ok, I can go with that
20:25:37 <abadger1999> So as long as the entries in the list all fall under that category, I'm okay with it.
20:25:52 <felixfontein> I don't think we'd accept a new collection with ignore entries from that list anyway, if they don't have a very, very good reason for them
20:26:11 <cybette> we might want to change the #topic, I got confused being afk for a few minutes :)
20:26:15 <abadger1999> I don't know a lot about the individual tests so I'll go on your recommendations in that regard
20:26:23 <abadger1999> I'll do that, thanks
20:26:54 <abadger1999> #topic Add a list of sanity tests that MUST not be ignored to the checklist: https://github.com/ansible-collections/overview/pull/139
20:27:12 <cybette> thanks abadger1999
20:27:27 <abadger1999> felixfontein: I suppose if we find that someone has a very good reason, then we could take it off the list at that time?
20:27:31 <abadger1999> Does that sound good?
20:27:50 <felixfontein> fine for me. there are a few others which are more important though, like doc-elements-mismatch
20:28:23 <abadger1999> <nod> works for me
20:28:40 <russoz> works for me as well
20:29:34 <abadger1999> Wordsmithing, I would take out ", for the sake of documentation completeness and accuracy" as we could add other tests to this list which do not have to do with docs in the future.
20:29:52 <gundalow> +1
20:29:55 <russoz> +1
20:29:57 <abadger1999> But I'm +1 for the pr
20:29:58 <felixfontein> and all the mutually_exclusive-* and required_* ones, parameter-alias-*, parameter-documented-multiple-times, ...
20:30:21 <felixfontein> I shouldn't have looked at the whole error list :)
20:30:28 <abadger1999> Heh :-)
20:30:43 <felixfontein> (https://docs.ansible.com/ansible/devel/dev_guide/testing_validate-modules.html#codes)
20:31:25 <russoz> felixfontein ha, yeah I only looked at the ones in the files today, but yeah we might have more to add
20:32:39 <felixfontein> new collections should have a very short ignore.txt file anyway, so I guess not having an explicit list works out fine usually
20:36:05 <russoz> ok, so I am changing the phrasing to shamelessly copy^W^Winclude the suggestions from abadger1999
20:36:37 <abadger1999> Cool
20:36:46 <abadger1999> I'm +1 on the PR with that change
20:37:33 <felixfontein> you probably need to remove the other two changes to avoid merge conflicts
20:40:23 <russoz> not sur eI've seen those, but I suppose nothing hard to handle
20:40:44 <russoz> s/sur eI've seen/sure I've seen/
20:41:07 <felixfontein> russoz: the other PRs haven't been merged yet
20:45:03 <abadger1999> So... what do we neeed?
20:45:06 <abadger1999> More people to vote?
20:45:52 <felixfontein> probably. got a bit quiet here :)
20:45:57 <abadger1999> #chair
20:45:57 <zodbot> Current chairs: abadger1999 cybette daniel-wtd dericcrago dmsimard felixfontein geerlingguy gundalow jillr resmo russoz
20:46:23 <abadger1999> Please vote on the proposal to add a list of tests which MUST NOT be ignored: https://github.com/ansible-collections/overview/pull/139
20:46:47 <russoz> +1
20:46:52 <felixfontein> +1
20:46:55 <abadger1999> +1
20:46:58 <gundalow> +1
20:47:21 <abadger1999> dericcrago, dmsimard : ?
20:47:21 <dericcrago> +1
20:47:53 <russoz> abadger1999 when can we expect those other PRs to go through? I will have to rebase mine after that
20:49:30 <felixfontein> hmm, the current state of the PR does not reflect what we discussed here earlier, right?
20:49:34 <abadger1999> russoz: I can merge yours first.
20:49:48 <dmsimard> was momentarily afk, let me catch up
20:49:52 <felixfontein> I thought the 'for the sake of documentation completeness and accuracy' part should go
20:49:56 <abadger1999> russoz: yeah, as long as you push your changes ;-)
20:50:55 <russoz> why, thank you! will be happy to :)
20:52:33 <gundalow> Anything else left, we are approaching the 2 hour marl
20:53:11 <russoz> all good from me, I have just pushed the changes to the PR
20:53:25 <gundalow> russoz: Thanks :)
20:53:32 <dmsimard> I'm +1 on the addition pending wordsmithing
20:53:33 <cybette> just a quick one, for those interested...
20:53:41 <cybette> #info CFP for Infra Management DevRoom at FOSDEM 2021 is open (until 31/12) https://cfp.cfgmgmtcamp.org/fosdem2021/cfp
20:53:50 <abadger1999> Looks good
20:53:50 <cybette> let's get some Ansible talks in!
20:54:25 <abadger1999> #info APPROVED Addition of tests which MUST NOT be ignored [+6, 0, 0]
20:54:33 <abadger1999> #topic Open floor
20:54:45 <abadger1999> Thanks cybette for the announcement!
20:54:54 <abadger1999> Anyone else with something they want to bring up?
20:54:57 <cybette> ah sorry I jumped the gun. I thought gundalow was doing last cal
20:55:02 <russoz> and I have to split, got another meeting in 6min... thanks guys, see ya
20:55:19 <gundalow> russoz: Thank you as always :)
20:55:33 <gundalow> REMINDER: This is the last Community Meeting of the year
20:55:38 <gundalow> PR Review day tomorrow
20:58:45 <felixfontein> :)
20:58:52 <felixfontein> thanks everyone!
20:59:07 <gundalow> Thanks all
20:59:14 <felixfontein> enjoy the remaining days of this year! if you're not around the next weeks ;)
20:59:17 <felixfontein> #endmeeting