19:01:19 <felixfontein> #startmeeting Ansible Community Meeting
19:01:19 <zodbot> Meeting started Wed Dec  2 19:01:19 2020 UTC.
19:01:19 <zodbot> This meeting is logged and archived in a public location.
19:01:19 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:19 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:01:21 <zodbot> gundalow: Error: Can't start another meeting, one is in progress.
19:01:26 <gundalow> hehe
19:01:32 <felixfontein> lol :)
19:01:35 <felixfontein> dericcrago gundalow samccann abadger1999 agaffney tadeboro russoz geerlingguy briantist samccann jillr dmsimard cybette acozine lmodemalcyberpear aminvakil gwmngilfen akasurde baptistemm: ping!
19:01:40 * gundalow waves
19:01:41 <dmsimard> o/
19:01:43 <jillr> o/
19:01:46 <felixfontein> #chair gundalow dmsimard jillr
19:01:46 <zodbot> Current chairs: dmsimard felixfontein gundalow jillr
19:01:49 <cybette> o/
19:01:53 <felixfontein> #chair cybette
19:01:53 <zodbot> Current chairs: cybette dmsimard felixfontein gundalow jillr
19:02:00 <felixfontein> andersson007_ excused himself for this meeting
19:02:01 * dericcrago waves
19:02:06 <felixfontein> #chair dericcrago
19:02:06 <zodbot> Current chairs: cybette dericcrago dmsimard felixfontein gundalow jillr
19:02:27 <felixfontein> #topic agenda: https://github.com/ansible/community/issues/539#issuecomment-737419444
19:02:33 <lmodemal> o/
19:02:34 <abadger1999> Good day :-)
19:02:41 <felixfontein> #chair lmodemal abadger1999
19:02:41 <zodbot> Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal
19:03:00 <geerlingguy> o/ (I'll be in and out for a bit)
19:03:10 <felixfontein> #chair geerlingguy
19:03:10 <zodbot> Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal
19:03:42 <felixfontein> today's meeting is mainly about criteria for inclusion of new collections into Ansible 3.0.0, though we will start with two quick other topics (after general announcements)
19:03:42 <gundalow> #info Bullhorn 15 has just been published https://mailchi.mp/redhat/the-bullhorn-15 (you should subscribe)
19:03:54 <felixfontein> #topic Announcements
19:03:58 <gundalow> #info Bullhorn 15 has just been published https://mailchi.mp/redhat/the-bullhorn-15 (you should subscribe)
19:04:05 <felixfontein> #info Ansible 2.10.4 has been released yesterday
19:04:09 <felixfontein> #info Ansible 2.10 contains new collections since last meeting: community.okd and community.hrobot (see https://github.com/ansible-collections/overview/issues/128 for overview)
19:04:14 <samccann> o/
19:04:18 <felixfontein> #chair samccann
19:04:18 <zodbot> Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal samccann
19:04:28 <gundalow> #info PR Day on 1st December was a great success, next is 17th December. Hope to see you there https://github.com/ansible/community/issues/407
19:05:17 <andersson007_> gundalow: good job as i wrote this morning
19:05:29 <felixfontein> #chair andersson007_
19:05:29 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal samccann
19:05:38 <andersson007_> felixfontein: i can't miss this meeting:)
19:05:46 <felixfontein> andersson007_: hehe :)
19:06:24 <felixfontein> #topic Are bugfix releases every ~3 weeks ok for community.general's stable-1 branch?
19:06:29 <felixfontein> Long version: are bugfix releases every ~3 weeks (i.e. shortly before Ansible 2.10.x releases) ok for community.general's stable-1 branch (assuming there is something to release, of course)?
19:06:52 <felixfontein> let's have a quick poll, if you're against it write -1, if you're for it write +1
19:07:03 <felixfontein> (I hope it doesn't need a longer discussion :) )
19:07:15 <gundalow> +1 (Regular is good, there's a continual flow of PRs merged into c.g)
19:07:24 <andersson007_> +1
19:07:25 <jillr> +1
19:07:28 <abadger1999> Note that syncing night always be a problem, for instance, were skipping a few weeks for the Christmas-new years holiday for the next Ansible release
19:07:28 <felixfontein> +1
19:07:31 <samccann> +1
19:07:41 <dmsimard> +1
19:07:45 <felixfontein> abadger1999: that's what the ~ is for ;)
19:08:10 <abadger1999> But i do like three weeks as it means even if it's out of sync, there's not long to wait to get the changes in
19:08:14 <abadger1999> +1
19:08:26 <felixfontein> we can revisit this once Ansible 3.0.0 and c.g 2.0.0 are out
19:08:38 <felixfontein> ok thanks!
19:08:59 <felixfontein> #agreed community.general 1.3.x bugfix releases will be ~every three weeks
19:09:23 <felixfontein> #topic Should the next 'big' Ansible release in February 2021 be Ansible 3.0.0, or a higher version number?
19:09:33 <nitzmahone> o/
19:09:41 <geerlingguy> 3.0.0 imo
19:09:48 <felixfontein> this question was brought up recently by nitzmahone (yesterday or the day before, I forgot)
19:09:51 <geerlingguy> either that, or like 42.0.0
19:09:56 <felixfontein> :)
19:10:07 <nitzmahone> ONE MILLION POINT OH
19:10:10 <felixfontein> 202102.0.0 :)
19:10:30 <abadger1999> I like 3.0.0 since the idea of the ansible package is to provide continuity for end users.
19:10:42 <felixfontein> I think 3.0.0 is already good enough, we'll have 4.0.0 out by middle of 2021, and 5.0.0 by the end of 2021 / beginning of 2022
19:10:43 <abadger1999> But I'm not overly married to it.
19:10:57 <abadger1999> <nod> Yeah.
19:10:59 <felixfontein> at that point ansible-core will probably still be in the 2.1x range with x small
19:11:11 <gundalow> We release ansible-3.0 in February 2021,  ansible-core releases  2.11 in April 2021, we release ansible-4.0 in May 2021, we release ansible-5.0 ~September 2021
19:11:12 <gundalow> or so, ansible-6.0 in February  2022 or so
19:11:17 <samccann> 3.0.0 has the benefit of we don't have to explain why we skipped up to a larger number like 10.0.0
19:11:36 <jillr> +1 3.0.0, for the continuity
19:11:42 <felixfontein> gundalow: is 5.0.0 in ~September a fixed thing? I think that would be too frequent, since major releases can have breaking changes
19:11:51 <cybette> +1 for 3.0.0
19:12:44 <nitzmahone> Yeah, my only concern was just that the average person probably hasn't figured out core vs packaged content yet, so "where's all the new 3.0 goodies?"... It's a pretty minor point of confusion, and it'll likely not be an issue for too long, but just wanted to raise it as something to think about
19:13:21 <felixfontein> nitzmahone: I'm not sure whether they also won't ask for that if we name it 42.0.0
19:13:25 <abadger1999> felixfontein: it's not... I would like to have about three releases a year, though.... I think february is a better month than January to release in so September could become October.
19:13:27 <gundalow> felixfontein: not fixed, more an indication that `ansible` numbers will move fast
19:13:30 <nitzmahone> Where if the number is far enough apart from 2.10/2.11, it'll at least be fairly clear that *something* changed
19:13:49 <resmo> o/
19:14:04 <acozine> o/
19:14:06 <abadger1999> #chair resmo
19:14:06 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal resmo samccann
19:14:09 <felixfontein> abadger1999: gundalow: I don't mind fast, we should just try to balance deprecations/removals vs. quick major releases, since every release which breaks things annoys users
19:14:09 <nitzmahone> felixfontein: I guess my point is that a larger version number makes someone curious, vs something that's very close to the existing core version they just assume it's business as usual
19:14:11 <abadger1999> #chair acozine
19:14:11 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal resmo samccann
19:14:28 <abadger1999> #chair nitzmahone
19:14:28 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal nitzmahone resmo samccann
19:14:35 <felixfontein> nitzmahone: true
19:14:49 <geerlingguy> I've been trained that even a 'minor' bump (even if it's not intended to be used as 'minor' versioning using Ansible's current versioning system can have major implications.
19:15:05 <geerlingguy> So 3.0.0 in Ansible-land feels like maybe a complete and total different thing than 2.anything
19:15:07 <abadger1999> Can we cut off discussion on this in... say 5 minutes?
19:15:15 <abadger1999> (So we can move to the next thing)
19:15:16 <felixfontein> abadger1999: definitely!
19:15:29 <felixfontein> let's do a definite vote in 2 minutes, so if you have more arguments, spit them out now :)
19:15:38 <abadger1999> <nod>
19:15:47 <nitzmahone> Yeah, I don't have anything more, just wanted to at least make sure it was a conscious choice rather than off-the-cuff
19:16:06 <geerlingguy> Either way it won't be too harmful I don't think—but I do know that with Perl, PHP, etc. whenever a major version is skipped, half the time after that release people waste having to explain what happened to the skipped numbers
19:16:12 <dmsimard> I think whatever the outcome, communicating about it and the core rename more broadly will be important
19:16:23 <abadger1999> VOTE: Next ansible release will be (a) 3.0.0     (b) 10.0.0
19:16:34 <samccann> I think anything separated from the core numbering 2.x will cause people to go huh? and dig for more info
19:16:35 <abadger1999> Oops, 30 seconds too soon
19:16:35 <felixfontein> a
19:16:45 <andersson007_> a
19:16:46 <dmsimard> a
19:16:46 <abadger1999> samccann: I agree
19:16:46 <cybette> a
19:16:47 <felixfontein> (c) some other number
19:16:48 <abadger1999> a
19:16:54 <jillr> a
19:16:57 <felixfontein> (if someone wants something else than 3.0.0 and 10.0.0)
19:16:58 <samccann> so long as we document it (potentially in botjh core and collection docs) we should be ok
19:17:00 <samccann> a
19:17:06 <resmo> a
19:17:23 <felixfontein> 3.0.0 should get a longer release summary then :)
19:17:36 <acozine> a
19:17:44 <lmodemal> a
19:18:51 <felixfontein> #agreed the next 'big' Ansible version will be 3.0.0 in February 2021. we'll add docs everywhere that explain that it is not much different than 2.11 would have been, so users hopefully won't expect something bigger
19:18:55 <felixfontein> thanks everyone! :)
19:19:03 <felixfontein> #topic Criteria for inclusion of new collections in Ansible 3.0.0
19:19:13 <felixfontein> abadger1999: do you have something prepared for this topic?
19:19:19 <nitzmahone> Cool- thanks for the discussion (and sorry I butted into the PR day yesterday with that, didn't realize it was mid-meeting).
19:19:29 <nitzmahone> #unchair nitzmahone
19:19:29 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal resmo samccann
19:19:33 <aminvakil> o/
19:19:54 <felixfontein> nitzmahone: thanks for putting it up!
19:19:56 <felixfontein> #chair aminvakil
19:19:56 <zodbot> Current chairs: abadger1999 acozine aminvakil andersson007_ cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal resmo samccann
19:19:58 <abadger1999> nitzmahone: it was fine yesterday too, PR day is less a meeting and more a working session where a lot of different things can come up.
19:20:24 <abadger1999> So last meeting, we discussed moving forward with criteria for new collections in ansible-3.0.0
19:20:35 <felixfontein> #info https://github.com/ansible-collections/overview/issues/131
19:20:53 <abadger1999> The first thing we need to do is create a framework that we can then modify.
19:21:35 <abadger1999> So for homework, everyone was to take a look at the present checklist and think of modifications to it that felll into two groups:
19:22:04 <abadger1999> (1) Things that you feel absolutely must be changed with the checklist before you can consider approving them as the basis for accepting new collections
19:22:25 <abadger1999> (2) Things to change in the checklist that are not blockers for your vote to accept them as criteria
19:22:49 <abadger1999> So to start today:  Has anyone come up with something in group (1) ?
19:23:08 <andersson007_> (1) at least1) matching ansible doc format and convensions 2) they must pass sanity tests
19:23:20 <andersson007_> maybe also  3) have unit and / or integration tests as for (1)
19:23:38 <abadger1999> (Here's the existing checklist: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst )
19:23:52 <samccann> seems like this is an opportunity to add stricter requirirements (for tests etc)
19:24:16 <felixfontein> (1): publicly available issue tracker; information on which kind of contributions are accepted (might also be none
19:24:21 <andersson007_> stricter requirements sounds good
19:24:29 <samccann> as in we arent blocking people from creating collections and put them in galaxy w/ minimal test etc... but we CAN block them from the Ansible package to enforce stronger quality requirements
19:24:31 <abadger1999> #topic Matching ansible doc format and conventions
19:24:49 <abadger1999> andersson007_:  Here's the existing section on documentation: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#documentation
19:24:57 <abadger1999> andersson007_: What is your proposed change?
19:25:27 <andersson007_> abadger1999: just wanted to mention it again, it's imo so important:)
19:25:34 <dmsimard> The thing I've been meaning to ask about is that those are more technical requirements but what are the non-technical ones, if any ? In other words, would we say ever say no to anyone who proposed a collection that meets the technical requirements ?
19:25:38 <abadger1999> Okay.
19:26:13 <abadger1999> #info existing checklist item on documentation is considered okay to start with.
19:26:23 <felixfontein> dmsimard: that's a very hard question :) I think we also need non-technical requirements, but it is very hard to formalize them
19:26:33 <dmsimard> For example, would we include two different nginx collections in Ansible ?
19:26:51 <abadger1999> #topic sanity tests
19:27:01 <abadger1999> Here's the existing sanity test checklist item: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#ci-testing
19:27:10 <abadger1999> Currently, the requirement is that they're run.
19:27:12 <samccann> ooo interesting question on the two similar collections - Ansible Thunderdome!  they have to fight it out
19:27:29 <gundalow> #agreed Collections MUST have sanity tests running against every major version of `ansible-core` that is supported by the collection
19:27:31 <jillr> dmsimard: I would vote no on that, what's in the ansible package should be somewhat ... I don't want to say authorative, but maybe prescriptive?
19:27:35 <felixfontein> they must run, and they must pass. you can have ignore.txt entries, though you should thrive to minimize them.
19:27:46 <abadger1999> Do we want to change that to "sanity tests must be passing"?  What is the leaway for things which should be ignored instead of changing the code to pass?
19:28:09 <andersson007_> felixfontein: +1
19:28:10 <dmsimard> jillr : yeah, it's just an example of a non-technical requirement I came up with but I'm sure there's more
19:28:16 <felixfontein> abadger1999: +1 for passing
19:28:24 <dmsimard> +1 for passing
19:28:25 <resmo> abadger1999, +1 for passing
19:28:30 <abadger1999> I like passing coupled with ignore.txt.
19:28:34 <jillr> passing, and any ignores should be well documented?
19:28:39 <samccann> can we perhaps put a limit on the types of tests that can have ignore.txt entries? So we are upping the requirements vs what was in say ansible-2.9?
19:29:00 <abadger1999> Do we want to encode anything about what can go in ignores.txt  right now?  Or leave that up to reviewers and modify that after we get some experience?
19:29:02 <jillr> like, there has to be a documented rationale for something to be ignored
19:29:08 <felixfontein> jillr: sounds good. it's totally fair to just add a bunch of ignore.txt entries when a new validator is added to ansible-test, but they should be cleaned up in appropriate time, and not kept around forever
19:29:21 <gundalow> We can grand father in existing collections, though we could require new collections to have empty `ignore-x.y.txt`(apart from where you can't fix them (something about docs for certain types of non-module plugin docs))
19:29:28 <samccann> not sure how much can be in ignores.txt but could a 'nefarious' collection owner just ignore everything and presto - they pass all sanity tests?
19:29:47 <felixfontein> samccann: in theory, you can ignore every error and have a HUGE ignore.txt
19:30:03 <gundalow> I'm 100% OK (and infact would strongly prefer) any new collection to be held to a much higher standard that the existing ones.
19:30:04 <jillr> samccann: that would be review of the reasons for the ignores would come in, and would be the basis for a discussion with the collection maintainer
19:30:13 <samccann> yeaeh I like the idea of it should be empty and if not, why not
19:30:31 <gundalow> "Any entries in ignore.txt must be able to be justified"
19:30:32 <aminvakil> i think this can be up to maintainer to decide, whether it's ok to put it in ignore.txt or not
19:30:39 <jillr> gundalow: +1
19:31:05 <andersson007_> +1 for much higher standards
19:31:16 <felixfontein> gundalow: +1
19:31:17 <samccann> +1 as well
19:31:23 <felixfontein> and +1 for higher standards too
19:31:28 <resmo> +1
19:31:32 <abadger1999> Are inline comments allowed in ignore.txt?
19:31:36 <felixfontein> abadger1999: yes
19:31:40 <abadger1999> Cool
19:31:47 <acozine> abadger1999: I would require one comment per entry
19:31:55 <felixfontein> abadger1999: https://github.com/ansible-collections/community.docker/blob/main/tests/sanity/ignore-2.11.txt#L1
19:32:01 <gundalow> abadger1999: yes
19:32:14 <acozine> so each entry must have an explanation
19:32:20 <gundalow> acozine: sounds good to me
19:32:28 <samccann> yeah i like that idea
19:32:36 <felixfontein> yes, that's a good idea
19:32:41 <aminvakil> acozine: +1
19:32:48 <gundalow> spoiler alert `# haven't bother to fix this yet` isn't a valid justification
19:32:54 <acozine> that makes it transparent and also raises the bar on adding to ignore.txt vs. fixing the problem
19:32:58 <felixfontein> gundalow: ooooh, crap :D
19:33:06 <andersson007_> :D
19:33:10 <gundalow> hehe
19:33:27 <abadger1999> VOTE Proposed addition to the  `CI Testing` entry:    `The sanity tests MUST pass but adding some tests to the ignore.txt file is an allowed method of getting them to pass.  All entries in ignores.txt MUST have a justification, preferably a comment in the ignore.txt file for each entry.  Reviewers can block acceptance of a new collection if they don't agree with the ignores.txt entries.`
19:33:46 <felixfontein> +1
19:33:48 <aminvakil> +1
19:33:52 <jillr> +1
19:33:52 <acozine> +1
19:33:53 <abadger1999> +1
19:33:54 <cybette> +1
19:33:59 <dericcrago> +1
19:34:01 <resmo> +1
19:34:01 <lmodemal> +1
19:34:04 <gundalow> +1 though remove preferably and make it a hard requirement
19:34:08 <andersson007_> +1 (but i'd exclude "preferably")
19:34:20 <samccann> +1 with gundalow's addition
19:34:23 <dmsimard> +1 on hard req
19:34:36 <acozine> "MUST have a justification, described in a comment in the ignore.txt"
19:34:47 <andersson007_> +1 acozine
19:34:51 <felixfontein> is  `# TODO` an acceptable comment for something that will get fixed in a couple of weeks, once the maintainer(s) have more time?
19:35:00 <gundalow> and we can link to https://github.com/ansible-collections/community.docker/blob/main/tests/sanity/ignore-2.11.txt#L1
19:35:00 <geerlingguy> +1
19:35:15 <gundalow> felixfontein: nothing is as permanent as a temporary solution
19:35:39 <acozine> this is for adding net new collections, right?
19:35:40 <resmo> gundalow, aye ;)
19:35:46 <gundalow> Whats the incentive for the collection owner to fix it once the collection has been included in `ansible.in`?
19:35:47 <felixfontein> acozine: yes
19:36:00 <acozine> I'd say they need to be clean when they get added or they never will be
19:36:10 <andersson007_> acozine: +1
19:36:12 <acozine> it's our best chance to influence the authors
19:36:15 <samccann> maybe we need an ignores.txt hall of shame for existing collections :-)
19:36:23 <acozine> heeheee
19:36:28 <gundalow> samccann: see Bullhorn#15
19:36:34 <resmo> btw, didn't find anything related to "license" in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
19:36:45 <jillr> do a periodic re-review of included collections?
19:36:46 <felixfontein> gundalow: I'm mainly thinking of something like 'validate-plugins has been merged in ansible/ansible' happening a couple of days before, and there's no time to go through all suddenly new ignore.txt entries to remove them before the deadline is reached in two days
19:36:55 <acozine> we have something in the docs now about "we know we don't follow this rule in all existing modules, don't make the problem worse"
19:37:00 <abadger1999> Cool
19:37:30 <gundalow> felixfontein: ah, OK. So can we add something like `against the `devel` branch it is OK to have temporary `#todo` items for newly added validation rules
19:37:34 <felixfontein> jillr: that's a good idea, I have no idea whether we have enough resoures for that though
19:37:35 <abadger1999> #agreed sanity test requirement updated to require passing with rules on using ignores.txt: https://github.com/ansible-collections/overview/pull/132/files#diff-dacab21f27a6aa218b8dcaafcf6f5685df0ab52f231afa16e7a9ab5284b72c68
19:37:42 <felixfontein> gundalow: that sounds good!
19:37:44 <dericcrago> maybe for a different discussion (around maintenance / continual inclusion), but what happens when the sanity tests change and start failing because someone either hasn't fixed or ignored?
19:37:56 <jillr> felixfontein: yeah the more I think about it, maybe it's an annual review? plan it out like a PR day?
19:38:06 <felixfontein> jillr: good idea!
19:38:11 <resmo> jillr, +1
19:38:15 <jillr> and perhaps shortly before Fest, since that's one of our best times to engage with partners and community
19:38:40 <resmo> yes, and on-site, plz ;)
19:38:42 <jillr> we could do a collections fix-up event at contributor summit or something
19:38:44 <felixfontein> jillr: should be sufficiently before the next major release though, so that there's time to inform collection maintainers that they don't satisfy the conditions anymore, and they have a bit time to fix it and avoid being removed
19:39:06 <samccann> and ignore.txt hackfest sounds good
19:39:23 <jillr> felixfontein: I dont think we'd want to remove right away? more as an opportunity to engage with the maintainer and help them get back on track,
19:39:23 <felixfontein> with special guest russoz ;)
19:39:23 <gundalow> #action gundalow to think about ignore.txt hackfest
19:39:37 <jillr> kicking them out should be only after attempts to get the collection back in order
19:39:44 <felixfontein> jillr: +1
19:40:01 <samccann> maybe there are categories of ignore.txt that can be 'easyfix' issues per collection
19:40:06 <gundalow> Kicking out is another whole set of things
19:40:32 <gundalow> This is good discussion, though I feel we are going slightly off topic from the inclusion criteria
19:40:44 <andersson007_> to exclusion criteria
19:40:47 <gundalow> #topic license for collections
19:40:50 <felixfontein> oh about CI.... we don't have any rule that says how often the sanity tests should run, right?
19:41:06 <gundalow> felixfontein: I'll add on PR and nightly to abadger1999 PR
19:41:11 <felixfontein> some collections only run them on commits/PRs, and if these only happen every few months, they might not even notice that they would need a lot of ignore.txt entries
19:41:34 <felixfontein> I guess a weekly built is also OK for smaller collections, but something that runs regularly would be great
19:41:42 <gundalow> OK, I'll add
19:41:43 <gundalow> NEXT
19:41:55 <gundalow> from resmo
19:41:55 <gundalow> >  didn't find anything related to "license" in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
19:42:11 <felixfontein> plugins need to be GPL 3.0+ licensed anyway
19:42:15 <gundalow> abadger1999: to be included in the `ansible` package, what licences must a collection be
19:42:30 <felixfontein> the whole collection needs to be compatible to GPL 3.0+ I guess
19:42:35 <gundalow> remembering these a net new files, not ones previously in ansible/ansible
19:43:00 <dmsimard> GPL v3 would be a pass, others would need to be considered
19:43:17 <abadger1999> felixfontein: yeah, plugins must be GPLv3+ is a necessary rule to comply with importing the ansible library
19:43:46 <abadger1999> But I think since the model is "What does a Linux distro do?", then modules and module_utils can be any open source license.
19:44:16 <abadger1999> Maintainers (and reviewers) will need to point out license incompatibilities if they spot them, though.
19:44:47 <felixfontein> since reviewers and maintainers usually aren't lawyers, I'd tend to define a list of approved collection licenses
19:45:07 <abadger1999> The FSF, Fedora, and OSI all have lists of open source licenses.
19:45:10 <felixfontein> new entries of the list need to be approved by someone who knows licenses well enough (RH legal?)
19:45:41 <felixfontein> abadger1999: I'd be happy to re-use an existing list :)
19:46:14 <jillr> if we're going to have a list of acceptable licenses IMO that should 100% be reviewed by RH legal
19:46:30 <abadger1999> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
19:46:31 <dmsimard> There is a minimal amount of literature for plugins here: https://docs.ansible.com/ansible/latest/dev_guide/developing_module_utilities.html#standard-module-utilities
19:46:59 <abadger1999> https://www.gnu.org/licenses/license-list.html
19:47:30 <abadger1999> https://opensource.org/licenses/alphabetical
19:47:37 <dmsimard> abadger1999: that last link lists apache v2 as compatible but I still got in trouble for initially licensing ara as apache v2 :)
19:47:52 <dmsimard> I didn't want to bother and re-licensed to gplv3 but still
19:48:13 <abadger1999> apache v2 and gplv3 are compatible.  But apache v2 and gplv2 are not compatible.
19:48:22 <abadger1999> all three licenses are open source.
19:48:53 <felixfontein> what exactly does 'compatible' mean here?
19:49:08 <felixfontein> can gplv3 code be used in an apache v2 project?
19:49:13 <felixfontein> or vice versa? or both?
19:49:25 <dmsimard> there be dragons (and lawyers)
19:49:39 <dmsimard> hence why I just re-licensed, was easier
19:49:46 <abadger1999> Also, I think I should have responded differently to whatfelixfontein said earlier..... plugisns must be licensed gplv3 compatible.... they don't necessarily need to be under the gplv3 themselves.
19:50:48 <felixfontein> dmsimard: thinking about licenses always scares me :)
19:50:58 <gundalow> abadger1999: FYI I CI Cron and ignore.txt example from felixfontein to https://github.com/ansible-collections/overview/pull/132/commits/a060bb028523d32b5666c42cf390ea70e54e1097
19:51:10 <jillr> it's all well and good for us to say let's pick the OSI or FSF lists, but there's nuance we could miss and we have lawyers for just these things
19:51:16 <abadger1999> felixfontein: it would mean: I have a plugin.  It imports ansible (GPLv3+).  Therefore, the license of my plugin must be compatible with the GPLv3.  I can license the plugin as Apache v2 because that is true.
19:51:39 <gundalow> jillr: yup, this might be why I ignored it from the original checklist :P
19:51:46 <gundalow> (back in 5)
19:52:02 <felixfontein> jillr: that's why I prefer an explicit list that can only be extended after consulting lawyers :)
19:52:15 <jillr> gundalow: so let's say the action item is "ask RH legal to help us write us some things about license requirements"
19:52:40 <gundalow> I'm OK for that list to be "GPLv3+" initially (assuming that's right) then after speaking to OSLegal we can add more
19:52:45 <dmsimard> jillr: it's clear that gplv3 is A OK, need to validate for the rest
19:52:46 <andersson007_> +1 to an explicit list
19:52:50 <jillr> as for the requirements list, we know we want guidance and restrictions about licenses but we're not going to solve that list here today
19:52:59 <jillr> dmsimard: yeah
19:53:01 <resmo> (would be great to have apache v2 on that list if possible, so I could "donate" apache cloudstack modules to apache)
19:53:05 <felixfontein> gundalow: abadger1999: I'm also fine with weekly CI, as long as it doesn't happen less recently
19:53:54 <jillr> do we need to vote to include licensing as a requirement for included collections?
19:54:10 <abadger1999> felixfontein: I'm a little unsure about CI requirements.... what CI (resources/examples of configuring free services/etc) do we provide for collection owners?
19:54:10 <felixfontein> jillr: I think it would be better
19:54:38 <felixfontein> abadger1999: we don't provide any services, but we have examples for GitHub Actions
19:54:51 <gundalow> I'd prefer that we don't spend more than 5 more minutes on licencing as I feel it will take hours otherwise
19:54:58 <felixfontein> and for small (open source / community) collections, what GH offers for free is sufficient
19:55:19 <felixfontein> abadger1999: https://github.com/ansible-collections/collection_template/blob/main/.github/workflows/ansible-test.yml
19:55:22 <gundalow> VOTE: For initial checklist can we copy the license requirements that we had for ansible/ansible (GPLv3+ and BSD for module_utils)
19:55:23 <abadger1999> I don't think I like requiring everything to be gplv3+ at the moment is workable.
19:55:24 <andersson007_> lets vote
19:55:35 <gundalow> abadger1999: oh?
19:55:41 <abadger1999> Yeah, okay, BSd for module_utils is what I was thinking of.
19:56:01 <felixfontein> let's try to extend the list quickly to some more licenses. though not today :)
19:56:04 <jillr> +1
19:56:14 <dmsimard> +1
19:56:16 <abadger1999> gundalow I'm going to write something more finished before we vote
19:56:20 <felixfontein> +1
19:57:07 <acozine> current documentation says GPLv3 or higher
19:57:08 <acozine> https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_checklist.html
19:57:26 <felixfontein> acozine: I think that's the + in GPLv3+
19:57:29 <abadger1999> Proposal: New licensing section in the checklist.  Licensing section will say: "At the moment, module_utils must be licensed under the BSD-3-clause license and all other content must be licensed under the GPLv3+.  We have a list of other open source licenses which are allowed as soon as we get red hat legal to approve such a list for us"
19:57:34 <resmo> https://www.apache.org/licenses/GPL-compatibility.html tldr, apache v2 okay to be in gplv3 code (like abadger1999 said) but not vis versa
19:57:51 <felixfontein> abadger1999: I don't think module_utils must be BSD, GPLv3+ is also fine IMO
19:58:22 <abadger1999> PROPOSAL: New licensing section in the checklist.  Licensing section will say: "At the moment, module_utils must be licensed under the BSD-3-clause or GPLv3+ license and all other content must be licensed under the GPLv3+.  We have a list of other open source licenses which are allowed as soon as we get red hat legal to approve such a list for us"
19:58:34 <felixfontein> the BSD requirement was mainly to allow re-use of generic code, but module_utils in collections is used for a lot of specific code that's not really optimized for being reused outside the collection
19:58:36 <abadger1999> PROPOSAL: New licensing section in the checklist.  Licensing section will say: "At the moment, module_utils must be licensed under the BSD-3-clause or GPLv3+ license and all other content must be licensed under the GPLv3+.  We will have a list of other open source licenses which are allowed as soon as we get red hat legal to approve such a list for us"
19:58:58 <abadger1999> Anything else people see before we vote on that?
19:59:29 <acozine> for module utils, current docs say BSD with exceptions https://docs.ansible.com/ansible/latest/dev_guide/developing_module_utilities.html#standard-module-utilities
20:00:20 <felixfontein> acozine: one could argue that this is mainly for ansible/ansible :)
20:00:29 <jillr> abadger1999: would it make sense to say "at the moment we follow the ansible/ansible licensing requirements [link to docs] and will have a list...."
20:00:41 <abadger1999> jillr: But we don't
20:00:55 <acozine> yeah, we can change the docs to reflect whatever we decide
20:00:59 <abadger1999> the current guidelines say that the core team approves.
20:01:10 <jillr> abadger1999: fair, I was trying to piece together the different docs links above^
20:01:11 <abadger1999> (for module_utils)
20:01:48 <felixfontein> one could interpret 'core team' as 'collection maintainers', but that's an interpretation
20:02:26 <abadger1999> <nod> Also... I don't think we want to be the arbitrators of that as a general rule.
20:02:43 <felixfontein> ok, we had more than 5 minutes, let's vote maybe?
20:02:57 <abadger1999> VOTE: New licensing section in the checklist.  Licensing section will say: "At the moment, module_utils must be licensed under the BSD-3-clause or GPLv3+ license and all other content must be licensed under the GPLv3+.  We will have a list of other open source licenses which are allowed as soon as we get red hat legal to approve such a list for us"
20:03:03 <felixfontein> I think the latest proposal is a good start; we can still adjust it next week if someone has a better idea until then
20:03:16 <felixfontein> +1
20:03:18 <andersson007_> +1
20:03:19 <jillr> +1
20:03:25 <resmo> +1
20:03:30 <abadger1999> yeah.... this week we need things that we think *MUST* be changed in order to approve the checklsit
20:03:31 <abadger1999> +1
20:03:38 <cybette> +1
20:03:39 <dericcrago> +1
20:03:49 <acozine> +1
20:04:06 <gundalow> +1
20:04:06 <felixfontein> also, if someone likes a license to be added to this list (like Apache), that should be tracked somewhere so we have something to ask RH legal
20:04:42 <samccann> +1
20:04:43 <gundalow> issue under `/overview/`
20:04:48 <andersson007_> we could add this to the checklist
20:05:14 <andersson007_> what felixfontein suggested
20:05:24 <felixfontein> andersson007_: it's a temporary thing, for until next week :)
20:05:31 <felixfontein> no need to add that to the checklist
20:05:42 <andersson007_> ok
20:06:07 <andersson007_> isn't the term short?
20:06:08 <dmsimard> +1
20:06:17 <felixfontein> we can add some generic "new licenses can be added to this list, but only after approval by RH legal", or something like that. we want to avoid that we can be used to DDOS RH legal ;)
20:06:19 <abadger1999> #action abadger1999 to find out who manages legal@fedoraproject.org and whether we can piggyback off of the list they maintain for our needs or need to setup our own review process and list with red hat legal.
20:06:37 <geerlingguy> +1
20:06:41 <felixfontein> abadger1999: +1
20:07:02 <gundalow> +1
20:07:06 <abadger1999> #agreed New licensing section to be added: https://github.com/ansible-collections/overview/pull/132/commits/7d93eb228f66a1bd581e0f014630af50891e7714
20:07:40 <abadger1999> #topic Make some things stricter
20:08:15 <abadger1999> samccann: You mentioned this.  Do you have a solid proposal?  If not, I would advise we move on and cover specific ideas as non-essential changes next week.
20:08:44 <gundalow> Or a list of potental things and maybe we can quickly approve some of them
20:08:56 <felixfontein> I think we should require that there's a publicly available issue tracker (you don't have to pay to register and create an issue) and a changelog
20:09:22 <felixfontein> (taken from jillr's issue https://github.com/ansible-collections/overview/issues/126)
20:09:29 <abadger1999> #topic Publically available issue tracker
20:09:42 <gundalow> +1
20:10:03 <gundalow> Is there any detail that needs to be included?
20:10:07 <jillr> +1, obv
20:10:10 <andersson007_> +1
20:10:11 <gundalow> jillr: :)
20:10:14 <felixfontein> also some expectation about handling security issues might be a good candiate to add
20:10:32 <felixfontein> +1
20:10:38 <jillr> I'd still like a SHOULD have a CoC
20:11:04 <aminvakil> +1
20:11:13 <samccann> sorry blinked and I missed my moment - but no, I didn't have anything concrete for 'make things stricter' other than what was already mentioned - better testing, limiting ignores.txt etc
20:11:18 <felixfontein> should = it's not a real requirement, though?
20:11:33 <gundalow> jillr MUST have a Coc (or link to Ansible's)
20:11:40 <samccann> +1 for must
20:11:41 <gundalow> oh, sorry, are we still on issue tracker
20:11:46 <jillr> felixfontein: I mean, I would like it to be a must but I would take a should
20:12:00 <samccann> my nickel - anything under the
20:12:06 <jillr> gundalow: sorry we should probably break down each item in #126 to individual topics
20:12:12 <abadger1999> To finish off issue tracker, could someone write up the proposal?
20:12:14 <samccann> ansible umbrella MUST have CoC that is at least as strong
20:12:16 <gundalow> nps, I continued it
20:12:22 <abadger1999> Something that we can add verbatim to the checklist
20:12:26 <jillr> abadger1999: will do, one moment
20:12:31 <abadger1999> (same with CoC)
20:12:40 <felixfontein> jillr: I'm fine with 'must' :)
20:12:49 <abadger1999> felixfontein: and same with the other things you mentioned on jillr's ticket ;-)
20:12:50 <gundalow> #agreed MUST have a public & free issue tracker
20:12:53 <gundalow> #topic CoC
20:13:05 <gundalow> #agreed MUST have a CoC (or if not fall back to Ansible's)
20:13:25 <gundalow> #topic Information on which kind of contributions are accepted
20:13:32 <felixfontein> +1
20:13:41 <abadger1999> Note that some organizations are likely to need to send any CoC through their legal department.
20:13:43 <gundalow> (sorry for (ab)using being judge jury and executioner there
20:13:47 <gundalow> )
20:13:51 <felixfontein> there are collections which do not accept PRs, which I find strange but is OK if explicitly stated
20:14:04 <gundalow> felixfontein: oh, got an example?
20:14:04 <abadger1999> (Red hat did when we wanted to include a CoC for Fedora's annual conference)
20:14:17 * jillr has proposed verbiage for issue tracker but doesnt want to jump topics
20:14:26 <felixfontein> gundalow: I have to check my archives, baptistemm once tried to submit docs fixes to a collection and they just closed the PR
20:14:47 <gundalow> jillr: cool, we can reivew the PR
20:14:52 <gundalow> felixfontein: urgh
20:14:55 <abadger1999> I'm still okay with requireing it for now, but wanteed to add that information as it likely excludes some organizations
20:14:55 <gundalow> I'd really like all collections to not only allow PRs, though to take them seriously
20:15:10 <acozine> abadger1999: that makes sense, a Code of Conduct could say anything, after all
20:15:29 * gundalow wonders if he cares about companies that don't place nice with OSS contributors
20:15:31 <briantist> just butting in to the meeting for a moment to say thanks for all the community efforts. It's been a great experience working with everyone, (special mention to felixfontein , dmsimard , & dericcrago ) getting `community.hashi_vault` going. `0.1.0` is released, you've all made the steps really easy for maintainers, and provided excellent support and guidance 🎉
20:15:47 <gundalow> briantist: Thank you so much for all you've done with it
20:15:47 <felixfontein> briantist: oh, cool, congrats for 0.1.0! :)
20:16:00 <dericcrago> yay!
20:16:23 <felixfontein> briantist: https://github.com/ansible-collections/overview/issues/128#issuecomment-730620516 got its second checkmark :)
20:16:50 <abadger1999> gundalow: Let's vote on the issue tracker verbiage?
20:17:40 <abadger1999> #topic issue tracker proposal for vote
20:17:53 <abadger1999> jillr: Go ahead and propose it for a vote
20:17:53 <felixfontein> gundalow: https://github.com/F5Networks/f5-ansible#bugs-issues https://github.com/F5Networks/f5-ansible/pull/1792
20:18:05 <jillr> PROPOSAL add to requirements: Must have a publicly available issue tracker, that does not require a paid level of service to create an account or view issues.
20:18:09 <geerlingguy> +1
20:18:12 <abadger1999> +1
20:18:26 <acozine> +1
20:18:33 <felixfontein> +1
20:18:39 <dmsimard> +1
20:18:45 <gundalow> +1
20:18:46 <aminvakil> +1
20:18:57 <andersson007_> +1
20:19:04 <cybette> +1
20:19:10 <samccann> +1
20:19:12 <resmo> +1
20:19:20 <aminvakil> felixfontein: wow, that's something!
20:20:02 <dericcrago> +1
20:20:35 <acozine> I guess not everyone has a bunch of F5 networking equipment just lying around to test on?
20:20:54 <resmo> felixfontein, so, some project like to have an "issue" in which they discuss and accept the issue to be fixed in a follow-up PR
20:21:18 <dmsimard> F5's are expensive too :)
20:21:20 <resmo> a PR without an "issue" will get closed.
20:21:25 <felixfontein> resmo: yep, and they don't really want a PR from an external person
20:21:34 <jillr> acozine: nope, just antique cisco gear  ;)
20:21:36 <abadger1999> #agreed publically available issue tracker requirement is accepted: https://github.com/ansible-collections/overview/pull/132/commits/280c53b566901875d54d312b28fbf086275133a3
20:21:48 <abadger1999> #topic Require a CoC?
20:21:55 <aminvakil> acozine: that was a doc fixing issue, that at least could be excluded
20:22:29 <resmo> felixfontein, that is strange, let's fork (..not) ;)
20:22:39 <dmsimard> CoC would be nice to have (we could encourage it) but I'm not sure if it should be a requirement
20:22:43 <felixfontein> resmo: I'd just avoid buying F5 equipment, it also saves money ;)
20:22:48 <abadger1999> #undo
20:22:48 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f379ca02b90>
20:22:51 <abadger1999> > #topic Information on which kind of contributions are accepted
20:22:59 <abadger1999> #topic Information on which kind of contributions are accepted
20:23:03 <baptistemm> felixfontein: their hardware is good
20:23:45 <samccann> CoC should not be a controversial concept. Create your own, or link to Ansible's. And should be required imo.
20:24:24 <felixfontein> baptistemm: could well be :)
20:24:45 <jillr> I'd certainly like to make it a requirement, if we say "required and make your own though" we get into "should be police what that CoC covers/contains"
20:25:02 <jillr> which I don't think we want to/should do
20:25:02 <abadger1999> gundalow: put in an agreed for CoC is a MUST, above.
20:25:03 <misc> samccann: well, depend what is in the CoC, I get the spirit, but that's like "you need to have a license" and people adding a non free license to check the box :/
20:25:08 <felixfontein> for community collections I think requiring CoC is fine. for company collections there seems to be a potential problem with legal having to approve a CoC. no idea how much that really is an issue
20:25:26 <jillr> also what felixfontein said
20:25:32 <samccann> 'CoC is required and must be at least as strong as Ansible. IF you do not want to create your own, add a CoC file that points to Ansible's'
20:25:49 <felixfontein> samccann: or just link to it from README :)
20:25:58 <gundalow> I'm confused, what topic are we on
20:26:12 <samccann> Ansible the package is only a community entity. If a company collections wants in, they go through the joy of getting a CoC approved imo.
20:26:25 <acozine> can we just do "all collections in the ansible package are governed by the Ansible CoC"?
20:26:45 <gundalow> jillr: does acozine idea work?
20:26:47 <jillr> acozine: I like that, it avoids a lot of possible pitfalls
20:26:49 <felixfontein> samccann: that's a good argument! they can put their collection on galaxy also without a CoC
20:26:51 <dmsimard> CoCs are ... political/governance things and not everyone is good with that
20:26:54 <abadger1999> I think the CoC proposal was accepted.  I wrote it up here: https://github.com/ansible-collections/overview/pull/132/commits/00a8e364ea6c962a59fa47f1c917fd5e97cf7e49
20:27:28 <abadger1999> Would people be okay with any changes to that being discussed  next week as "Not necessary to get my vote to approve intial criteria" ?
20:27:34 <acozine> abadger1999: sure
20:27:47 <samccann> abadger1999 - I'd change it to acozine's idea.. but sure we can handle next week
20:27:50 <felixfontein> abadger1999: there was no real discussion about CoC above, it was mainly gundalow deciding after a very short discussion
20:27:57 <jillr> it's also possible to write things into a CoC that I think are not in line with our goals, so I like "governed by Ansible's"
20:28:03 <abadger1999> Heh, yeah....
20:28:22 <acozine> I feel like in any instance where a CoC violation comes up, we want to know exactly what our position is
20:28:26 <samccann> maybe a very quick vote to say 'governed by Ansible's
20:28:41 <abadger1999> So the present topic is: which kind of contributions are accepted.
20:28:53 <acozine> abadger1999: sorry
20:28:54 <felixfontein> I like acozine's idea, though we probably have to exclude (some?) collections that have been grandfathered in
20:29:11 <jillr> apologies - wrt topic, I think we're in need of verbiage for this item?
20:29:12 <abadger1999> gundalow: I think that's in reference to dmsimard's statement about whether there are nontechnical things to be  put onto the checklist?
20:29:59 <felixfontein> (or at least give them a grace period to either accept our CoC, or be removed from ansible)
20:30:52 <abadger1999> dmsimard: to continue that, do you have a solid proposal?  I think there might be nontechnical things but that's not something we'll just put o nthe checklist, probably.
20:31:35 <samccann> 'Before you create a collection, ensure a similar collection does not already exist in Ansible'
20:32:03 <samccann> that would cover the tw nginx collections conundrum for example
20:32:07 <abadger1999> So, that speaks to a fundamental question about what ansible is....
20:32:09 <samccann> s/tw/two/g
20:32:12 <felixfontein> samccann: I'd rather say "Before applying for inclusion into Ansible, ensure ..."
20:32:22 <abadger1999> If the model is, Ansible  is a linux distribution, then I would be -1 to that proposal.
20:32:22 <samccann> yeah that's better
20:32:33 <samccann> can you elaborate?
20:32:47 <dmsimard> abadger1999: I don't have a proposal ready, was mostly pointing out that there are such non-technical requirements that could prevent a collection from being included
20:33:04 <abadger1999> You can have two diferent groups competing in the same space and both should be valid.... example from the Linux distro model: GNOME and kde  (or vim, emacs, xemacs, and nano)
20:33:43 <acozine> what are the objections to having two nginx collections included?
20:34:00 <acozine> tidyness? size of the package?
20:34:01 <dmsimard> I don't know, are there any ? :)
20:34:19 <felixfontein> I guess having an official nginx collection (by the company) would allow having another one (community.nginx)
20:34:20 <geerlingguy> end-user confusion, mainly (I think)
20:34:30 <aminvakil> geerlingguy: +1
20:34:38 <acozine> we have two AWS collections, right?
20:34:41 <jillr> "if a collection already exists that provides the same or similar functionalty, there should be documentation of the differentiating features"?
20:34:50 <geerlingguy> though we could find ourselves in some places hitting the problem of "this not-included one is way better and way-better maintained... can we replace the one already built in with it?"
20:35:00 <samccann> Okay thinking out loud - when I install Fedora, it comes with gnome
20:35:01 <felixfontein> jillr: and a good reason why both should be included :)
20:35:11 <dericcrago> geerlingguy - I was just thinking that as well
20:35:29 <samccann> i can replace that with kde.. .but similarly, I can install Ansible with nginx-foo... but then decide to manually install nginx-bar from galaxy
20:35:35 <dmsimard> I guess my question could be re-phrased as: do we systematically approve collections for inclusion in the ansible package if they meet the technical requirements (tests, issue tracker, etc.) ?
20:36:03 <felixfontein> dmsimard: I would avoid that, otherwise the ansible package grows and grows...
20:36:07 <jillr> dmsimard: that, or should we be curating what goes into the package?
20:36:13 <felixfontein> (it already does, but it would grow much faster)
20:36:18 <abadger1999> jillr: I like that... on the other hand, it means that new collections are forcing changes on older collections: ie: someone doesn't like the current amazon collections so they start a project to make their own.  Now the owner of the original amazon collection has to help out with documenting the differences
20:36:39 <jillr> I'm personally in favor of curation; in the AWS collections example there's minimal overlapping modules and clear differences
20:36:57 <dmsimard> felixfontein, jillr: right, so how do we formalize the non-technical criterias used for that kind of curation
20:37:09 <jillr> abadger1999: and that's happened, but I'm pretty sure we're not shipping the other collection in the ansible package
20:37:21 <felixfontein> abadger1999: the other only has to add documentation if the reviewers decide that the new collection should be included too (because it does some things better than the existing one)
20:37:53 <samccann> Originally, Ansible the package was 'provide a way for the old 'batteries included' that was 2.9
20:37:56 <jillr> abadger1999: I was assuming the burden to document was on the new collection, though it's a good question once we get into curation
20:37:59 <abadger1999> felixfontein: <nod> unrestrained growth is an issue.  OTOH, if the model is a Linux distribution, then growth is something we know as inescapable as well.
20:38:23 <samccann> do we want to say now that Ansible the package is 'everything that passes the technical hurdle"  or 'something that passes and also meets with XXX nontechnical requirements'
20:38:24 <dmsimard> abadger1999: we have a package manager (think yum or apt) by way of galaxy, though
20:38:32 <felixfontein> abadger1999: one could see galaxy as the linux distribution, ansible-core as the kernel, and ansible as the 'default installation'
20:38:46 <samccann> ^^ that's what I'm thinking
20:38:51 <dmsimard> felixfontein: yeah, that's in line with what I had in mind
20:38:53 <jillr> yeah I like that.
20:39:16 <felixfontein> galaxy can have 50 different nginx collections, but ansible doesn't have to include them all if they are technically fine
20:39:32 <abadger1999> dmsimard: I don't think that's the right analogy... But i've said i nthe past that I think we're lacking an important piece to make everything fit.
20:39:40 <abadger1999> samccann referenced that above too..
20:39:43 <felixfontein> we include usually at most one, or two (or more) if they are sufficiently different and both seem to be useful to a lot of people
20:40:09 <felixfontein> dmsimard: it's a package manager which is pretty bad at upgrading and dependency resolving ATM ;)
20:40:29 <aminvakil> felixfontein: could we agree on a defined criteria on that?
20:40:51 <abadger1999> I think that ansible-galaxy is more like pip install than yum install (because those are uncurated by us).  The ansible package is currently doing double duty as both "curated by us" and "installed by default".
20:40:55 <dmsimard> felixfontein: right but it's not like fedora or ubuntu ships with all the packages already installed
20:41:12 <felixfontein> aminvakil: I guess it's only possible to have a soft criteria with a lot of freedom for the review committee
20:41:25 <aminvakil> would sufficiently different be enough? if the new collection is doing something "sufficiently different" can't they be merged into one collection?
20:41:46 <abadger1999> I think eventually, to solve the growth problem, we're going to have to separate "curated" from  "default"
20:41:47 <felixfontein> dmsimard: definitely!
20:41:49 <aminvakil> felixfontein: my question is how can that be more formal?
20:41:52 <dmsimard> aminvakil: we can encourage and foster that but enforcing it is out of scope
20:41:54 <abadger1999> But we don't have that yet.
20:41:57 <jillr> merged two collections into one if they have different maintainers is outside of our control
20:42:16 <aminvakil> felixfontein: jillr oh, sure
20:42:34 <samccann> Is there a list of net new collections already wanting to be part of Ansible 3.0.0?
20:42:59 <felixfontein> I'd be interested in such a list, but I think there isn't one yet
20:43:18 <abadger1999> samccann: I know of one.
20:43:30 <samccann> I'm just wondering if we can hold off on net new collections until 4.0.0 while we work out the nontechnical requirements (if any)
20:43:38 <felixfontein> I think it would be nice to include community.sops (but I shouldn't decide on that one since I'm involved in it)
20:43:42 <abadger1999> We will need to create a procedure for allowing people to submit those and get them reviewed and approved as well.
20:43:58 <abadger1999> No, we can't hold off on net new collections.
20:44:04 <felixfontein> samccann: having a few concrete collections to discuss for 3.0.0 will make it easier to formalize rules for 4.0.0
20:44:44 <abadger1999> Net new content has been put off for years (going back to ansible-bsae when the committers stopped reviewing all of hte new modules and plugins)
20:45:01 <abadger1999> It's one of the big things we've telling people (including partners) they can expect in 3.0.0
20:45:56 <samccann> ah gotcha.. thanks for the background abadger1999
20:46:48 <acozine> +1 to felixfontein's idea of "let's use the first three/five/dozen new collections as examples as we develop non-technical requirements for adding collections"
20:46:51 <samccann> could we potentially use galaxy download stats to help decide what gets in? As in it has to be on galaxy for xxx months and have at least yy downloads to say it's worth inclusion?
20:46:53 <dericcrago> would "demand" be a non-technical requirement?
20:47:13 <felixfontein> how about we say that for 3.0.0 the review process will be more strict, to allow us to have a better set of rules for 4.0.0? i.e. collections rejected for 3.0.0 can try again for 4.0.0 (and will have more information on what they can improve / whether they have a chance)
20:47:20 <acozine> dericcrago: as in, "I demand that you include my.special_collection"? ;-)
20:47:22 <dmsimard> samccann: that's not a bad idea -- demonstration of use and care and maintenance
20:47:43 <resmo> samccann, well, some CI jobs might influence this stat
20:47:46 <jillr> acozine: I think more like "strategic value"
20:47:55 <jillr> I'm not sure how we would quantify that in the community though
20:47:58 <felixfontein> samccann: not sure how much these stats really say. if you install a collection in CI that runs 10 times per day, it has a lot more downloads than another one that's used by 100 persons who only install it once
20:48:02 <dmsimard> felixfontein: it feels like an "all rights reserved to the reviewers" thing which I was hoping to put into better writing than that
20:48:26 <dericcrago> acozine - hehe, I could see that side of it, for sure, but I was actually thinking, "we're not seeing any demand for this". although, I'm not sure how you would really measure that
20:48:31 <samccann> yeah i recall hearing that about galaxy stats. I wonder if something 'under the covers' might distinguish between 'real' downloads and CI test runs
20:48:36 <dmsimard> s/all rights reserved/to the discretion/
20:48:37 <felixfontein> dmsimard: it definitely is, and I like to get rid of it, but I'm not sure we can for 3.0.0 without really knowing what we can expect
20:49:25 <felixfontein> ansible.netcommon is installed by quite a few collection CIs for example; community.crypto as well, and community.general too - so the download numbers for them could be very misleading
20:49:27 <jillr> dmsimard: maybe something like, acceptance is ultimately at the discretion of the review board but an rejected collections will be given feedback in the decision?
20:49:54 <jillr> so folks at least know decisions aren't being made in a vacuum, at some person's whims?
20:49:57 <dmsimard> jillr: until we can come up with something better
20:50:14 <dmsimard> but then we'd probably need to document governance, the actual board, etc
20:50:24 <resmo> .oO(anonymous usage opt-in stats for ansible?)
20:51:04 <felixfontein> resmo: I belong to the group of people who never enables that, so I personally don't believe in such stats ;)
20:51:19 <jillr> I'm ok with governance and docs, but maybe that's a 4.0 thing?
20:52:02 <dmsimard> yeah I don't think we'll figure that out /right now/, it's probably best to leave a small discretionary clause for the time being
20:52:28 * acozine AFK ten minutes
20:52:44 <felixfontein> dmsimard: definitely!
20:53:20 <dmsimard> jillr had a good draft there
20:53:33 <resmo> okay, folks, I am off. o/
20:53:38 <felixfontein> good night resmo!
20:53:45 <jillr> cya  o/
20:54:27 <samccann> need to step away for about 15 min
20:55:01 <jillr> I'm going to need to wrap up soon as well, where are we at on topics and things we can still action today?
20:55:11 <gundalow> resmo: thanks
20:57:07 <felixfontein> I think we stopped recording results of the discussion, at least here
20:57:18 <dmsimard> writing a proposal
20:57:18 * acozine back
20:58:20 <dmsimard> PROPOSAL: Add a clause "Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee."
20:58:23 <felixfontein> we had CoC, what kind of contributions are accepted, what is ansible + growth problem, discussion how we can add more soft limits
20:58:39 <dmsimard> "community review committee" wording up for debate
20:59:06 <jillr> I'm +1 that text as a starting point
20:59:08 <gundalow> dmsimard: +1
20:59:09 <felixfontein> dmsimard: I would extend it with "Every rejected candidate will get feedback, and we try to have more precise rules for Ansible 4.0.0."
20:59:15 <felixfontein> +1
20:59:24 <jillr> +1 felixfontein's addition
20:59:33 <acozine> +1 for original plus addition
20:59:34 <aminvakil> dmsimard: felixfontein +1
21:00:08 <jillr> PROPOSAL to Documentation section: What type of contributions are accepted, if any, and the method for submitting contributions must be documented.  This documentation SHOULD be in a CONTRIBUTING file in the root of the repository.
21:00:50 <dmsimard> felixfontein: works for me
21:01:08 <felixfontein> jillr: would a section in README also be ok?
21:01:30 <jillr> felixfontein: works for me; should be in a contributing or readme file in...
21:01:41 <felixfontein> jillr: +1
21:02:07 <acozine> +1 for including suggestions with rules
21:02:32 <acozine> (as jillr's proposal does)
21:03:16 <felixfontein> extended PROPOSAL: Add a clause "Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee. Every rejected candidate will get feedback, and we try to have more precise rules for Ansible 4.0.0."
21:03:43 <dmsimard> #chair
21:03:43 <zodbot> Current chairs: abadger1999 acozine aminvakil andersson007_ cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal resmo samccann
21:03:45 <dmsimard> ^ vote please
21:03:46 <jillr> +1 extended proposal
21:03:47 <dmsimard> +1
21:03:48 <felixfontein> I'm +1 for jillr's proposal, and +1 for the extended proposal
21:03:51 <aminvakil> +1
21:04:08 <cybette> +1
21:04:23 <dericcrago> +1 for both
21:04:26 <acozine> +1 for both
21:04:41 <gundalow> +1
21:05:03 <lmodemal> +1
21:05:22 <felixfontein> if you just write +1, do you mean the extended proposal, jillr's proposal, or both?
21:05:35 <dmsimard> +1 for both :)
21:05:41 <aminvakil> +1 both
21:05:58 <dmsimard> abadger1999: ok with you ?
21:06:04 <cybette> +1 for both
21:07:04 <geerlingguy> +1
21:08:40 <jillr> I've got to run, thanks everyone for a long and productive meeting!
21:08:48 <acozine> jillr: ciao!
21:08:55 <felixfontein> jillr: thakns for all your contributions to it :)
21:09:11 <felixfontein> #agreed Add to documentation section: "What type of contributions are accepted, if any, and the method for submitting contributions must be documented.  This documentation SHOULD be in a CONTRIBUTING file in the root of the repository, or mentioned in the README."
21:09:15 <felixfontein> #agreed Add a clause "Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee. Every rejected candidate will get feedback, and we try to have more precise rules for Ansible 4.0.0."
21:09:23 <abadger1999> -1 from me
21:09:29 <samccann> back
21:09:30 <felixfontein> (I added the README mention to jillr's proposal, I hope that's fine)
21:09:40 <felixfontein> abadger1999: -1 for which one?
21:09:42 <dmsimard> abadger1999: can you elaborate ?
21:09:47 <felixfontein> #undo
21:09:47 <zodbot> Removing item from minutes: AGREED by felixfontein at 21:09:15 : Add a clause "Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee. Every rejected candidate will get feedback, and we try to have more precise rules for Ansible 4.0.0."
21:09:48 <felixfontein> #undo
21:09:48 <zodbot> Removing item from minutes: AGREED by felixfontein at 21:09:11 : Add to documentation section: "What type of contributions are accepted, if any, and the method for submitting contributions must be documented.  This documentation SHOULD be in a CONTRIBUTING file in the root of the repository, or mentioned in the README."
21:09:48 <abadger1999> Sorry, i had to take my kid to an appointment and i hadn't expected this meeting to run into that
21:10:04 <felixfontein> abadger1999: sorry, this meeting is ALWAYS taking way too long ;)
21:10:59 <gundalow> felixfontein: always lots of good stuff happening
21:14:03 <gundalow> Shall we end here?
21:14:14 <dmsimard> waiting on abadger1999 to elaborate on -1
21:16:04 <gundalow> ah, wasn't sure if he'd had to head off again
21:17:01 <felixfontein> me neither, 'had' sounded like past tense, but it might have been a result of quickly typing something on the phone or so
21:17:03 <samccann> maybe just action that we'll discuss contribution requirements next week?
21:17:16 <aminvakil> samccann: +1
21:17:26 <gundalow> samccann: yup
21:17:29 <felixfontein> #info Discuss next time: Add to documentation section: "What type of contributions are accepted, if any, and the method for submitting contributions must be documented.  This documentation SHOULD be in a CONTRIBUTING file in the root of the repository, or mentioned in the README."
21:17:34 <felixfontein> #info Discuss next time: Add a clause "Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee. Every rejected candidate will get feedback, and we try to have more precise rules for Ansible 4.0.0."
21:18:13 <gundalow> samccann: acozine would you be able to wordsmith https://github.com/ansible-collections/overview/pull/132 over the next day
21:18:14 <github-linkbot> https://github.com/ansible-collections/overview/pull/132 | open, created 2020-12-02T19:34:58Z by abadger: Must change changes to the checklist criteria
21:18:54 <acozine> gundalow: sure, we can look at that
21:19:03 <gundalow> acozine: thanks, then we can get that merged
21:19:16 <gundalow> Thanks all
21:19:19 <gundalow> #endmeeting