19:00:15 <felixfontein> #startmeeting Ansible Community Meeting
19:00:15 <zodbot> Meeting started Wed Nov 18 19:00:15 2020 UTC.
19:00:15 <zodbot> This meeting is logged and archived in a public location.
19:00:15 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:15 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:20 <felixfontein> hi all!
19:00:27 <briantist> 👋
19:00:30 <samccann> \o
19:00:34 <jillr> o/
19:00:34 * gundalow waves
19:00:40 <dericcrago> hi
19:00:40 <abadger1999> Greetings :-)
19:00:40 <felixfontein> #chair briantist samccann jillr gundalow
19:00:40 <zodbot> Current chairs: briantist felixfontein gundalow jillr samccann
19:00:44 <felixfontein> #chair dericcrago abadger1999
19:00:44 <zodbot> Current chairs: abadger1999 briantist dericcrago felixfontein gundalow jillr samccann
19:00:54 <dmsimard> \o
19:01:01 <abadger1999> #chair dmsimard
19:01:01 <zodbot> Current chairs: abadger1999 briantist dericcrago dmsimard felixfontein gundalow jillr samccann
19:01:02 <cybette> o/
19:01:04 <felixfontein> andersson007_: acozine: geerlingguy: resmo: gwmngilfen: cyberpear:
19:01:09 <felixfontein> #chair cybette
19:01:09 <zodbot> Current chairs: abadger1999 briantist cybette dericcrago dmsimard felixfontein gundalow jillr samccann
19:01:24 <acozine> o/
19:01:25 <felixfontein> ah right andersson007_ isn't around today
19:01:29 <felixfontein> #chair acozine
19:01:29 <zodbot> Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein gundalow jillr samccann
19:01:53 <felixfontein> #topic agenda: https://github.com/ansible/community/issues/539 (the last few comments)
19:01:59 <dmsimard> #chair geerlingguy
19:01:59 <zodbot> Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann
19:02:14 <felixfontein> welcome everyone!
19:02:18 <geerlingguy> #halp
19:02:21 <cyberpear> hi
19:02:26 <felixfontein> #chair cyberpear
19:02:26 <zodbot> Current chairs: abadger1999 acozine briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann
19:02:27 <geerlingguy> aww, I wanted to see what that does
19:02:29 <aminvakil> hi
19:02:34 <felixfontein> #chair aminvakil
19:02:34 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann
19:02:56 <dmsimard> #help
19:03:04 <cyberpear> geerlingguy: send a message to the Fedora Community operations Channel
19:03:04 <felixfontein> anyone else who wants to become furniture, just say hi :)
19:03:08 <dmsimard> geerlingguy : no such thing I guess
19:03:24 * gwmngilfen is doing bedtime, but can dip in if stats things come up
19:03:27 <felixfontein> #topic announcements
19:03:52 <felixfontein> #info community.docker, community.postgresql and community.routeros 1.0.0 were released this week and will be included in the next Ansible 2.10 release
19:04:07 <felixfontein> (they contain content moved out from community.general and community.network)
19:04:14 <abadger1999> Yaaay
19:04:34 <felixfontein> #info The Bullhorn 14 has been published today: https://mailchi.mp/redhat/the-bullhorn-14
19:04:34 <briantist> 🎉
19:04:37 <gundalow> #info Next two Ansible PR days are Tue 1st Dec and Thu 17th December. Calendar invite is in https://github.com/ansible/community/issues/407 Hope to see you there
19:04:42 <felixfontein> #chair briantist
19:04:42 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann
19:05:01 <geerlingguy> that's a lotta bull
19:05:35 <samccann> heh
19:05:43 <cybette> :D
19:05:48 <acozine> geerlingguy: we're bullish?
19:05:48 <abadger1999> #info Ansible-2.10.4 will be released on Tues, 1st Dec (or possibly 2nd December according to timezones ;-)
19:05:55 <dmsimard> it's... incredibull
19:05:56 <felixfontein> #info please review https://github.com/ansible-collections/community.general/pull/1303 and https://github.com/ansible-collections/community.general/pull/1304, in particular the changelog fragments, since we will replicate them a lot
19:05:56 <github-linkbot> https://github.com/ansible-collections/community.general/pull/1303 | open, created 2020-11-14T19:43:15Z by felixfontein: [WIP] Add information on docker module migration [WIP,affects_2.10,docs,has_issue,needs_triage,owner_pr]
19:06:09 <gwmngilfen> Adora-bull
19:06:10 <felixfontein> geerlingguy: as long as it's not a bull's hit.
19:06:11 <lmodemal> Hello o/
19:06:16 <felixfontein> #chair lmodemal
19:06:16 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal samccann
19:06:20 <felixfontein> #chair gwmngilfen
19:06:20 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen jillr lmodemal samccann
19:06:37 <geerlingguy> lol my watch is going insane, it vibrates at every mention
19:07:12 <felixfontein> :)
19:07:20 <felixfontein> does anyone else have an announcement to make?
19:07:37 <geerlingguy> I am eating a turkey sandwich
19:07:47 <gundalow> #info No IRC Meeting next week (25th Nov) as lots of people are off that week
19:07:48 <dmsimard> hmmm ansible/devel is ansible-core now
19:08:01 <dmsimard> no public announcement material yet
19:08:14 <gundalow> #info ansible/ansible is now `ansible-core` (previously ansible-base) https://github.com/ansible/ansible/pull/72594
19:08:16 <github-linkbot> https://github.com/ansible/ansible/pull/72594 | closed, created 2020-11-12T00:53:41Z by relrod: Rename to ansible-core [affects_2.11,bug,shipit,support:community,support:core,test]
19:08:19 <gundalow> dmsimard: thanks for the reminder
19:11:00 <felixfontein> abadger1999 suggested to do some quick votes first on the release schedule and semantic versioning for the ansible package, and then discuss inclusion of new collections in 2.11 since that's getting more urgent
19:11:18 <gundalow> +1
19:11:47 <abadger1999> #topic Semantic versioning of the ansible package
19:11:52 <felixfontein> I'm fine with that, as long as nobody objects to dellemc.openmanage to be included in ansible 2.10, assuming they run at least sanity checks in public CI (I hope they have more checks running somewhere, but not visible publicly)
19:12:09 <felixfontein> #info related proposal: https://github.com/ansible/proposals/issues/179
19:12:42 <felixfontein> semantic versioning would be for the ansible package, not for ansible-base/ansible-core
19:12:51 <felixfontein> right?
19:12:58 <abadger1999> (Let's have a quick vote on dellemv.openmanage inclusion too, after the two release  votes)
19:12:58 <gundalow> +1
19:13:04 <abadger1999> Correct
19:13:25 <abadger1999> ansible-core is talking about semantic versioning but even if they do that, it won't be soon.
19:13:27 <felixfontein> does anyone wants to discuss this, or needs more information etc., or should we just vote?
19:14:18 <acozine> I'm catching up rather quickly
19:14:18 <geerlingguy> vote?
19:14:19 <samccann> does anyone see a downside/problem with having Ansible use semantic versioning?
19:14:39 <acozine> does this mean the next release of the `ansible` package on PyPI would be `3.0`?
19:14:43 <gundalow> samccann: it's different to what we do today, though I known generally speaking, people have asked for it
19:14:46 <abadger1999> I have the proposal to vote on once we're done with discussion
19:15:07 <abadger1999> acozine: Yes, the next major release (In February) would be 3.0.0.
19:15:16 <samccann> gundalow: yeah I'm in favor of it for sure. Just wanted to know if anyone has identified potential gotchas (big gotchas)
19:15:21 <felixfontein> so no ansible 2.11
19:15:27 <abadger1999> The -evrey-three-weeks releases of that will look like 3.1.0, 3.2.0, etc.
19:15:29 <abadger1999> Yep.
19:15:38 <geerlingguy> Main gotcha is probably that we'll be on version like 35 by 2023
19:15:42 <abadger1999> Instead of 2.11.0, we'll release 3.0.0
19:15:46 <geerlingguy> But Firefox is up to what? 82 now?
19:15:46 <felixfontein> and if we have to do a re-release like recently, we'll get a patch release
19:16:04 <dmsimard> would it be confusing to have mismatched version numbers between ansible-core and ansible ?
19:16:10 <acozine> thanks for the details abadger1999 felixfontein
19:16:14 <geerlingguy> that's already happening dsim
19:16:18 <geerlingguy> dmsimard: ^
19:16:19 <cyberpear> I don't like it. I think major version bumps should indicate major breakage
19:16:20 <gundalow> dmsimard: that's almost a feature
19:16:20 <tadeboro> dmsimard: We are already there ;)
19:16:25 <samccann> What's the downstream impact?  aka will this cause grief from The Powers That Be on the RH side or did we already talk to them about this?
19:16:46 <felixfontein> dmsimard: it's already confusing, since there are two different 2.10.x streams
19:17:12 * ikhan_ waves
19:17:17 <felixfontein> #chair ikhan_
19:17:17 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr lmodemal samccann
19:17:18 <abadger1999> dmsimard: We're going to have that anyway (if we stayed with 2.11, we'd have ansible-base-2.10 and ansible-2.11, followed by ansible-core-2.11 and ansible-2.12)
19:17:24 <acozine> no matter what version number we give to the next release, there will be a mismatch between ansible-core and ansible
19:17:29 <abadger1999> So diverging more quickly is probably less confusing overall
19:17:37 <dmsimard> understood
19:17:56 <gundalow> By the end of 2021 `ansible` would be on 5.0.0, while `ansible-core` would likely be 2.11
19:18:05 <gundalow> These are all good questions to ask :)
19:18:10 <acozine> abadger1999: I agree that using 3.0 next would be easier to explain . .. well, not explain, but make it easier to see at a glance which thing we're talking about
19:18:10 <tadeboro> How often would a major version be released (sorry if this piece of info is already somewhere)?
19:18:19 <abadger1999> samccann: We have reached out to thaumos and robyn and they both approved.
19:18:23 <samccann> cyperbear: can you elaborate?  To me, Ansible the package is all about the collections included.. .which are using semver.  So making it also use semver seems logical to me.
19:18:34 <gundalow> tadeboro: for `ansible` major version bump every ~3-4 months
19:18:47 <felixfontein> #chair tadeboro
19:18:47 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr lmodemal samccann tadeboro
19:18:49 <cyberpear> I still think we should tie the version of the community distribution to the core package
19:18:50 <jillr> I actually kinda like having different ansible/ansible-core versions, to clarify that one is a meta packaging of multiple components with different dev cycles
19:19:13 <gundalow> as that will allow `ansible` to pull in the new major versions of the collections (which by definition would have breaking changes)
19:19:29 <dmsimard> cyberpear: many users asked about whether 2.10 should have been called 3.0 to begin with -- I'm personally torn on that but recognize that the shift to collections is likely significant enough to warrant calling it as such
19:19:36 <abadger1999> jillr: Corrext.  the ansible package is depends on some major version of the ansible-core package + includes specific versions of certain colletcions.
19:20:01 <jillr> I've already had folks in issues trying to test with different ansible-base versions but not different collection versions because it's not obvious that ansible-base has no effect on the collection rev to them
19:20:02 <tadeboro> So 3-4 versions a year is not that bad. And how long do we intend to support backward-compatibility? 2 years?
19:20:23 <geerlingguy> I still wish 2.10 were 3.0
19:20:28 <samccann> cyperpear: I struggle to see how we can keep the Ansible version tied to ansible-core version and still bring in new collections and breaking changes.
19:20:29 <jillr> abadger1999: right but I feel like it helps community that these things are not 1:1 equivalents
19:20:32 <abadger1999> tadeboro: The current plan is that only the latest release of ansible is supported.
19:20:36 <jillr> s/community/communicate
19:20:37 <geerlingguy> It didn't break my playbooks technically, but it's a totally new Ansible (IMO)
19:20:37 <resmo> geerlingguy, +1
19:20:42 <felixfontein> tadeboro: depends on the collections
19:21:14 <abadger1999> tadeboro: I have a feeling we're going to need to re-discuss and re-vote on that when ansible-3.0 comes out or when ansible-4.0 comes out (4.0 will rebase onto ansible-core-2.11 so it will be a more major release)
19:22:03 <tadeboro> Potentially breaking playbooks three times a year does not sound good.
19:22:40 <felixfontein> I think two major versions a year are enough potential breakage
19:22:44 <bcoca> for that case you would stick with ansible-core instead
19:23:08 <tadeboro> I know c.g and other community collections will make sure this does not happen. But I have less trust in certified collections (as weird as this sounds).
19:23:12 <gundalow> ansible-core (pinned) + collections you care about (pinned)
19:23:15 <geerlingguy> what bcoca said — I know I hope to start moving more of my work to `ansible-core` as time goes on
19:23:33 <gundalow> (version pinned)
19:23:34 <geerlingguy> that gives 'ansible the giant package' more room to be experimental
19:23:43 <abadger1999> Oh, or are you talking about the deprecation cycles?  If so, what felixfontein is saying is the answer... individual collections control their own deprecation cycles.  The ansible package will have new major releases with potential backwards incompatible changes from the collections 3-4 times a year.
19:23:52 <bcoca> only issue is people have relied on 'ansilbe' package being 'the stable' one, but that is now reve4rsed
19:24:23 <felixfontein> bcoca: ansible wasn't really stable, every new 2.x.0 release had breaking changes
19:24:37 <tadeboro> We just wrote a modern intro to Ansible that instructs users to handpick the content they use, but there is a lot of existing content and no one to migrate it.
19:25:35 <jtanner> hello folks
19:25:46 <felixfontein> most existing content should just work (assuming you installed the right collections)
19:25:59 <samccann> so from the sounds of it, Ansible always had some level of breaking changes... and users had to adapt to each upgrade... and we are saying the same will happen with Ansible going forward, yes?
19:26:10 <abadger1999> Okay.... I think we're getting into a different topic.
19:26:15 <samccann> except we'd be back to a 3-4 times a year cadence
19:26:17 <felixfontein> samccann: yes
19:26:21 <felixfontein> hi jtanner!
19:26:23 <felixfontein> #chair jtanner
19:26:23 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro
19:26:51 <abadger1999> I think they're less urgent than the three things I would like to get to today.
19:26:59 <jillr> samccann: it sounds to me like yes, but by putting those under major version numbers it should be more obvious that it would happen? and we give folks a way to not break, by sticking with ansible-core revs that move slower
19:27:33 <samccann> agreed jillr
19:27:39 <samccann> sorry abadger1999
19:27:46 <abadger1999> tadeboro: Can I put: ansible package release cadence and deprecation cycle onto the agenda (probably for discussion in December since I think net-new collection policy is going to take up the next few meetings)?
19:28:24 <tadeboro> abadger1999: Sure. It was not my intention to block the meeting at all.
19:28:28 <abadger1999> Cool.
19:28:35 <dmsimard> +1, I think it's a good topic to discuss
19:28:37 <felixfontein> ok. vote, or postpone this topic?
19:28:42 <abadger1999> If we're ready, here's my proposal to vote on:
19:28:43 <tadeboro> Vote.
19:28:44 <abadger1999> VOTE: The next major release of ansible will be 3.0.0; Ansible releases will follow semantic versioning going forward from there.
19:28:47 <dmsimard> s/discuss/discuss later/
19:28:52 <gundalow> +1
19:28:53 <geerlingguy> +1
19:28:55 <jillr> +1
19:28:55 <felixfontein> +1
19:28:56 <tadeboro> +1
19:28:56 <dmsimard> +1
19:28:57 <abadger1999> +1
19:28:59 <acozine> +1
19:29:03 <briantist> +1
19:29:04 <dericcrago> +1
19:29:07 <felixfontein> #chair
19:29:07 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro
19:29:20 <samccann> +1
19:29:20 <cybette> +1
19:29:31 <cyberpear> -1
19:29:51 <aminvakil> i rather not to vote on this
19:29:53 <jtanner> -1 if "ansible" is refering to the thing formerly known as ACD
19:30:12 <gundalow> jtanner: correct
19:30:27 <gundalow> jtanner: could you explain why you are `-1`?
19:30:45 <acozine> I'm curious - cyberpear you said you'd like to tie `ansible` releases to `ansible-core` releases
19:30:54 <acozine> jtanner: what would you prefer for versioning?
19:31:32 <jtanner> because aside from the branding, the language features are what i associate to the version of "ansible" and content/collections/etc aren't additions to the language imho
19:32:04 <felixfontein> #agreed The next major release of ansible will be 3.0.0; Ansible releases will follow semantic versioning going forward from there (12 x +1, 1 x 0, 2 x -1)
19:32:41 <cyberpear> yes, tying them together would be my preference. ansible being a meta package... also agree w jtanner
19:32:42 <samccann> jtanner - I would love Ansible the package to have a different name... it would sure help with all of this.
19:32:50 <ikhan_> @gundalow so what will be the feature different between 2.10 and 3.0 (other than new collections content)?
19:33:10 <geerlingguy> if ansible-core were developed hand-in-hand with all the collections then I could agree (but would still like core to use semver heh)... but it's not
19:33:17 <felixfontein> ikhan_: none. but there are breaking changes for modules and plugins
19:33:20 <tadeboro> jtanner: I would consider the union of all included collections' APIs as something that must follow the rules of semver since this is what playbooks use.
19:33:40 <felixfontein> I agree with tadeboro
19:33:42 <abadger1999> jtanner: I do agree with that idea, however, at current, the language is defined by the ansible-core package so I think that the ansible-core package probably needs to reflect the language version instead of the ansible package.
19:34:06 <jtanner> maybe ... i did say "imho"
19:34:07 <tadeboro> jtanner: You break my playbook once, I will fix it. Do it twice in a row, I am looking for something more stable ...
19:34:15 <abadger1999> ikhan_: new collections ocntent which can have backwards incompatibilities.
19:34:18 <felixfontein> roles/playbooks can break. it doesn't matter whether it's a language feature which changes, or one of the modules/plugins they use
19:34:23 <geerlingguy> tadeboro: heh, /me nervously looks at Ansible 2.3, 2.4, and 2.5
19:34:28 <ikhan_> @felixfontein so because we are carrying breaking changes in collections technically the whole package is not backward compatible - is that true?
19:34:34 <geerlingguy> tic-tac-toe on those three releases breaking things
19:34:48 <abadger1999> ikhan_: correct
19:34:50 <felixfontein> ikhan_: yes
19:35:09 <gundalow> Linux kernel version isn't related to Distro version
19:35:13 <geerlingguy> I think the main concern (at least for me) is the end-user optics. 99% of Ansible users are not writing python modules and things like that, they write playbooks
19:35:35 <geerlingguy> Go language version is not related to Kubernetes version... etc.
19:35:45 <jtanner> gundalow: the difference is that the kernel is not the interface to the linux distro, whereas core is the interface here
19:35:46 <samccann> gundalow: agreed... but then we also have - linux distros have different names.  They aren't called just Linux
19:35:47 <felixfontein> usually if you stick to a smaller set of collections, new major releases will be needed way less often. but having a huge amount of different collections that release independently, we need regular major releases
19:35:52 <ikhan_> so we do meet the criteria for reving major version
19:36:05 <jillr> I'm slightly less concerned with the name of the meta package and more interested that it has its own versioning/cadence based on its contents
19:36:15 <geerlingguy> ikhan_: yes, probably frequently (2-3x per year)
19:36:21 <samccann> jillr++
19:36:35 <geerlingguy> so we'd be on "Ansible 7" or so in 2022
19:36:55 <jillr> though we should pick a name and stick with it for a good long while, and not keep changing it
19:37:48 <felixfontein> geerlingguy: otherwise we'd be at 2.17, which would have as many breaking releases as 7.0.0
19:38:10 <geerlingguy> Yep, except everyone else is like "wow Ansible is so outdated, they still are on version 2 after 5 years"
19:38:11 <ikhan_> if every collection/ansible-core(base) is on their own rev number and Ansible package is at their own rev then binding ansible package to ansible-core does not make any sense
19:38:41 <felixfontein> ikhan_: it is not bound to the ansible-core version anyway
19:39:04 <felixfontein> they coincidently have the same version until next february, then they will have different versions
19:39:26 <ikhan_> @felixfontein makes sense - it's just the naming makes it confusing
19:39:29 <aminvakil> it might be quite obvious, but i can't understand this. is there a reason to release a new minor version every 3 week, which would result in having breaking changes in 3 or 4 months?
19:39:41 <tadeboro> ikhan_: Collections release versions as they fit, so there is not bond between any collection version number or ansible(-base,-core) release.
19:39:52 <abadger1999> geerlingguy: yes.... that was something that thaumos liked, btw, because it causes less confusion with ansible-core versions.  I like it because model for the ansible package is now "Fedora and other Linux distros" and the major version reving in Fedora is actually a very good model for something that's an aggregate.
19:40:04 <abadger1999> ikhan_: +1
19:40:39 <abadger1999> aminvakil: The new minor version every 3weeks is so that bugfixes can be made to the ansible package.
19:40:45 <abadger1999> (on a predictable schedule)
19:41:07 <tadeboro> aminvakil: The main "breaker" of compatibility are collections, and we have no control over some of them.
19:41:07 <felixfontein> aminvakil: it's essentially the same thing we do right now, except that we use semver
19:41:17 <geerlingguy> Yeah like Fedora is on what, 34 now? CentOS/RHEL are on 8
19:41:23 <geerlingguy> it seems to work out
19:41:39 <abadger1999> Question: Is there anyone who would like to change their vote?  Otherwise we need to move on.
19:41:48 <geerlingguy> We could just call it "Ansible Community Edition" to clear up the confusion
19:41:55 <samccann> heh
19:41:58 <geerlingguy> Ansible CE for short, like `docker-ce`
19:41:59 <jtanner> +1
19:42:01 <abadger1999> There's one more "easy" vote ;-) and a humongous discussion yet to get to today ;-)
19:42:11 <geerlingguy> Though I know you start getting legal, marketing, product, etc. people all in a tizzy with that :D
19:42:44 <aminvakil> tadeboro: gotcha
19:42:57 <felixfontein> geerlingguy: current docker-ce version is 19.03.13-ce - the first two parts are year and month. says a lot about how alive and kicking it is :)
19:43:03 <gundalow> DING DING DING: Given the above discussion does anyone want to change their vote?
19:43:30 <ikhan_> abadger1999: it make sense to me and I am ok with 3.0.  the only concern that I have is that it will be very confusing for the consumers of the package to figure out why this change happened.  It needs to be clearly articulated and I don't know how that will happen
19:43:37 <dericcrago> basing releases on a fixed amount of time sounds more like calver than semver to me
19:43:56 <jtanner> +1
19:44:17 <acozine> dericcrago: if we ever have a release with no breaking changes in collections, we will only tick up the x.y+1.z
19:44:18 <aminvakil> +1
19:44:29 <cybette> +1 ikhan_
19:44:55 <abadger1999> #topic Release schedule for ansible-3.0.0
19:45:15 <felixfontein> ok, new topic :)
19:45:21 <abadger1999> I brought this up last meeting.  Since then I have gotten sign off from internal people.
19:45:40 <felixfontein> #info tentative schedule for 3.0.0: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
19:45:40 <abadger1999> So I'd like to get a vote here to approve it on the community side.
19:45:46 <abadger1999> https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
19:45:53 <felixfontein> I guess we only vote on the 3.0.0 part, not on the 4.0.0 part
19:45:53 <abadger1999> #info Proposed schedule: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
19:46:12 <abadger1999> Correct.  The 4.0.0 part is informational but it's too tentative at this point to vote on.
19:46:43 <abadger1999> So... it's basically, do you approve this section of the doc: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Schedule-for-Ansible-30
19:47:07 <gundalow> Looks good to me
19:47:13 <abadger1999> The only change from last week is that I added dates for net-new collections to be added.
19:47:19 <abadger1999> 2020-12-16: Finalize rules for net-new collections submitted for the ansible release.
19:47:30 <abadger1999> 2021-01-16: Final day for net-new collections to be **reviewed and approved.**
19:47:52 <abadger1999> Hmm... mistake on the latter date
19:48:28 <abadger1999> Should be 2021-01-27 Final day for net-new collections to be **reviewed and approved.**
19:48:32 * abadger1999 corrects the document
19:48:49 <felixfontein> #info 2020-12-16: Finalize rules for net-new collections submitted for the ansible release.
19:48:59 <felixfontein> #info 2021-01-27: Final day for net-new collections to be **reviewed and approved.**
19:49:27 <dmsimard> when we say "finalize rules for net-new collections", is there anything to look at yet ?
19:49:37 <felixfontein> dmsimard: that will be the next topic of discussion :)
19:49:51 <geerlingguy> hehe, we're executing these things in parallel, out-of-order execution
19:49:53 <felixfontein> resp. after a quick discussion on a specific collection
19:50:00 <geerlingguy> (though that criteria is probably the most contentious)
19:50:05 <abadger1999> VOTE: Approve https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Schedule-for-Ansible-30 as the release schedule for Ansible-3.0.0
19:50:14 <felixfontein> +1
19:50:15 <tadeboro> +1
19:50:16 <jillr> +1
19:50:17 <samccann> +1
19:50:18 <abadger1999> +1
19:50:18 <cybette> +1
19:50:49 <dmsimard> +1
19:50:55 <ikhan_> +1
19:51:03 <gundalow> +1
19:51:03 <cyberpear> +1
19:51:03 <aminvakil> +1
19:51:27 <cyberpear> beta and RC seem quite close together, but I guess it's fine for a meta-package
19:52:31 <felixfontein> cyberpear: since there is no new ansible-core version, should be fine
19:52:42 <felixfontein> cyberpear: the proposed schedule for 4.0.0 has a lot more time
19:52:44 <abadger1999> cyberpear: yeah.  I included the tentative schedule for the 4.0.0 release because I think the beta/rc/final period for 3.0.0 can be short whereas the beta/rc/final period for 4.0.0 needs to be much longer (more potential blockers because we're rebasing against ansible-core-2.11 in that releae)
19:53:04 <abadger1999> Cool, anymore votes for the schedule topic?
19:53:16 <acozine> +1 (sorry, mind was wandering)
19:53:31 <felixfontein> #chair
19:53:31 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro
19:53:48 <dmsimard> felix knows the cheat code to ping everyone
19:53:52 <geerlingguy> +1
19:54:09 <felixfontein> #agreed approved https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Schedule-for-Ansible-30 as the release schedule for Ansible 3.0.0 (13 x +1)
19:54:17 <felixfontein> ok
19:54:45 <abadger1999> Okay, cool.... Now for the big topic...
19:54:48 <gundalow> #action gundalow to copy https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Schedule-for-Ansible-30 to reddit
19:55:08 <jtanner> there's a "bigger" topic?
19:55:27 <felixfontein> #topic inclusion of dellemc.openmanage (https://github.com/dell/dellemc-openmanage-ansible-modules/tree/collections) in 2.10.x for transfer of some content from c.g (https://github.com/ansible-collections/community.general/pull/948)
19:55:35 <gundalow> jtanner: these were juts the wamups
19:55:38 <felixfontein> this is hopefully a quick one :)
19:55:38 <abadger1999> Oh, right :-)
19:55:44 <dmsimard> that's not the big one yet :p
19:55:45 <abadger1999> One more quick vote first
19:55:46 <jtanner> oh, is this the "new content" topic?
19:55:58 <abadger1999> Yeah, net-new content will be coming up right after this.
19:56:21 <felixfontein> we have several moves of content from c.g/c.n/other collections to new collections and will include them in Aansible 2.10.x, but this one is a bit special since the collection contains much more than the moved content
19:56:48 <felixfontein> the content moved is 2 x module_utils, 3 x modules (and tests)
19:57:06 <felixfontein> the collection has a lot more content: https://galaxy.ansible.com/dellemc/openmanage
19:57:55 <geerlingguy> woah
19:58:01 <jillr> I lack historical context so I'm going to abstain; I also need to step away for a couple minutes
19:58:09 <geerlingguy> I don't see any CI in their repo?
19:58:10 <dmsimard> who/what is the driver for including it before we formalize rules on adding collections ?
19:58:18 <geerlingguy> how can we guarantee quality?
19:58:30 <dmsimard> ^ what I mean by formalizing rules
19:58:47 * geerlingguy do you even test?
19:59:16 <abadger1999> I am okay with the increase in content.... My rationale is that if it was moved first and got into 2.10.4, the new content could be added to the collection after that and then the new collection would get into 2.10.5.... Separating the change between the two versions would be an artificial time barrier without any user benefit that I can see.
19:59:21 <geerlingguy> changelog is also not using antsibull-changelog (fwiw)
19:59:27 <gundalow> No CI at the moment, I raised a PR though GitHub Actions don't seem to be enabled https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 (though in my fork a lot is failing)
19:59:27 <github-linkbot> https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 | open, created 2020-11-18T12:57:28Z by gundalow: WIP Run ansible-test sanity & units
19:59:29 <dmsimard> looks like gundalow has a WIP for CI here here: https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174
19:59:30 <github-linkbot> https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 | open, created 2020-11-18T12:57:28Z by gundalow: WIP Run ansible-test sanity & units
20:00:02 <geerlingguy> there's a whole lotta red there
20:00:11 <abadger1999> If the new collection doesn't follow the checklist, then that is a different issue that I might have a problem with.
20:00:20 <felixfontein> geerlingguy: if changelog would be an argument, ansible would shrink noticable :)
20:00:29 <geerlingguy> true, just putting that out there
20:00:49 <geerlingguy> the idea being that it would be nice, as we balloon ansible ever-larger, if we were able to maintain at least a minimum set of requirements
20:01:01 <gundalow> Passing `ansible-test sanity` is a requirement to be included in `ansible`
20:01:06 <geerlingguy> 'passes sanity' would be absolute lowest minimum I think
20:01:28 <geerlingguy> 'has integration tests' would also be nice, but maybe not an absolute requirement
20:01:29 <dmsimard> right now we have https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
20:02:05 <geerlingguy> dmsimard: yeah, it does mention sanity
20:02:23 <felixfontein> geerlingguy: I'm also not 100% happy with it, but right now I'm happy about everything we can remove from c.g/c.n, and including it would be a reason to remove some more content fromm c.g
20:02:51 <gundalow> geerlingguy: we will get onto requirements in the next #topic, though yes `sanity` is the bare min, and I'd love to raise the bar a lot hire
20:03:15 <felixfontein> I would assume that they have better tests, but not in a public CI. but that's something we'll have to ask for.
20:03:31 <dmsimard> felixfontein: if it is not an emergency (which it doesn't seem like it is), I'd wait until we formalize rules on inclusion to ansible
20:03:31 <felixfontein> (maybe I'm also too optimistic :) )
20:03:45 <felixfontein> dmsimard: fine for me
20:04:09 <dmsimard> do we want a formal vote or table it for a next meeting ?
20:04:10 <felixfontein> VOTE: a) add collection now, b) reconsider after we have the rules set up
20:04:19 <felixfontein> b
20:04:20 <dmsimard> b
20:04:20 <gundalow> b
20:04:22 <aminvakil> b
20:04:23 <cybette> b
20:04:29 <tadeboro> b
20:04:34 <abadger1999> b
20:04:39 <samccann> b
20:04:39 <dericcrago> b
20:04:49 <geerlingguy> b
20:05:00 <felixfontein> sounds good :)
20:05:11 <geerlingguy> felixfontein: do they have an issue open somewhere where they're requesting the inclusion? (I don't know if we have the process so formal yet)
20:05:18 <geerlingguy> but we could stick this decision in there too
20:05:33 <felixfontein> #agreed we will reconsider dellemc.openmanage once the rules for inclusion in 2.11 have been set up
20:05:45 <felixfontein> geerlingguy: right now they only have a PR with requrest for removal of content from c.g
20:05:54 <felixfontein> https://github.com/ansible-collections/community.general/pull/948
20:05:55 <github-linkbot> https://github.com/ansible-collections/community.general/pull/948 | open, created 2020-09-23T08:52:50Z by rajeevarakkal: Remove DellEMC collections from community.general collectons [affects_2.10,feature,has_issue,module,module_utils,needs_maintainer,needs_revision,new_contributor,plugins,remote_management,stale_ci,tests,unit]
20:06:00 <felixfontein> which indirectly (for us) means inclusion in 2.10/2.11
20:06:02 <geerlingguy> It'd be nice to have some meta issue somewhere, maybe in a community repo
20:06:06 <geerlingguy> (in general, not just for this one)
20:06:07 <felixfontein> sorry, 3.0.0, I keep saying 2.11 :D
20:06:38 <gundalow> Meta issue to track what exactly?
20:06:40 <felixfontein> geerlingguy: for the current set of collections, there's https://github.com/ansible/community/issues/539#issuecomment-720085434 which I regularly update
20:06:47 <dmsimard> I sympathize that they've had that PR opened since september
20:06:49 * jillr back
20:07:18 <felixfontein> wb jillr!
20:07:29 <felixfontein> ok, let's start with the big discussion ;)
20:07:37 <gundalow> one sec
20:07:40 <felixfontein> ok
20:07:47 <jillr> just in time  :)
20:08:12 * cybette always triple/quadruple check version numbers when compiling bullhorn. having ansible 3.0.0 might make things easier :)
20:08:24 <geerlingguy> @felixfontein - nice. Probably good to figure out a way to get that list moved into something more manageable once we get further down this path
20:08:42 <gundalow> #agreed we will revisit including dellemc.openmanage after we've had the longer discussion around inclusion criteria. Though at the moment they don't run `sanity` https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174
20:08:43 <github-linkbot> https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 | open, created 2020-11-18T12:57:28Z by gundalow: WIP Run ansible-test sanity & units
20:08:46 <gundalow> felixfontein: ok, next topic
20:08:48 <abadger1999> #topic Criteria for new collections to be included in ansible-3.0.0
20:09:02 <felixfontein> #info Proposal: https://github.com/ansible/community/issues/539#issuecomment-729844717
20:09:19 <felixfontein> someone wants to present the proposal? abadger1999 gundalow?
20:09:37 <abadger1999> So given the schedule calls for getting ansible-3.0.0 out in february and we have people who want to submit their new collections for that, we need to get the criteria for those collections approved ASAP.
20:10:18 <abadger1999> I propose that we discuss using the existing checklist:  https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst   as the basis for the cirteria.  Discuss today and either vote on it today or the first thing at the next meeting (2 weeks from now)
20:10:42 <abadger1999> Then we spend two meetings discussing and voting on any changes to the checklist.
20:11:16 <abadger1999> On the December 16th meeting, what have approved is the criteria for ansible-3.0.
20:11:40 <abadger1999> Does that overall plan sound good?
20:11:57 <abadger1999> If there's no objections, I'll open discussion of the current checklist.
20:12:06 <geerlingguy> Ideally the bar is low enough to not make it a major hindrance, but high enough that we don't end up with a zillion duplicate things across many collections (e.g. all-the-galaxy-roles-built-into-ansible)
20:12:09 <gundalow> #info We are happy for the inclusion criteria (https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst) to become stricter to help improve the quality of the collections that are shipped in `ansible`. If you have an idea please mention in IRC or raise a PR directly against collection_requirements.rst to clarify & improve
20:13:03 <abadger1999> #info Discuss current checklist today, approve it as a basis for the guidelines no later than beginning of meeting on December-2-2020.
20:13:26 <abadger1999> #info Discuss and approve changes to the guidelines on December-9 and December-16
20:13:54 <abadger1999> #info Guidelines that have been approved by the end of the Dec-16 meeting will be the criteria for new collections in ansible-3.0.
20:14:07 <abadger1999> #topic Discuss and approve the current checklist
20:14:15 <gundalow> geerlingguy: yup, it's a balancing act, which makes it difficult
20:14:17 <abadger1999> #info The current checklist: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
20:14:55 <dmsimard> having personally gone through that list when standing up community.google and community.kubevirt, there was nothing particularly shocking to me although there are opportunities to make it easier for maintainers to meet the criteria
20:14:58 <felixfontein> I think the current checklist is a good starting point!
20:15:08 <abadger1999> Is there anything in the current checklist that people think should not be in the list?
20:15:42 <abadger1999> Is there anything that peoplefeel must be in the checklist otherwise they cannot vote to approve it as the baseline that we'll build from?
20:15:43 <geerlingguy> Another thing that I wonder if we don't cover well is what if there are collections that are basically just a bunch of roles?
20:15:44 <felixfontein> if you can think of something only after this meeting, that's also fine, we can still remove more things next meeting. or add things.
20:15:57 <jtanner> geerlingguy: and who's nginx install role is the best one?
20:16:24 <tadeboro> That document needs a version overhaul based on the semver vote today.
20:16:28 <geerlingguy> Do we plan on including those in Ansible, or excluding? I don't plan on submitting any, mostly because I believe roles are better separate from Ansible itself, but I guarantee there will be some people/orgs who will want to dump 50+ roles in for managing something or another
20:16:30 <jillr> abadger1999: I think we should require more details about community/repo management, https://github.com/ansible-collections/overview/issues/126
20:16:49 <geerlingguy> jillr: agreed
20:16:54 <jillr> what do we do if a repo shows up with no issue tracker for example? (ie; uses gerrit alone)
20:16:57 <felixfontein> I'm not against including role-only collections, but that will definitely be challenging
20:17:18 <abadger1999> Hmmm....
20:17:18 <dmsimard> we were discussing how ansible-lint is run when publishing a collection but I forget if it fails publishing if there is an error/warning
20:17:40 <geerlingguy> One other thing: we don't have anything in there about security — e.g. if there's a CVE filed, it would be nice to make sure there's some documented way of contacting someone who maintains the collection?
20:17:44 <dmsimard> I mention that because ansible-lint is missing from that doc
20:17:51 <abadger1999> jillr: Does that also mean we're requiring vendors to have their repositories publically available?
20:17:53 <jillr> also agree we need an overhaul based on semver, for example the #versioning-and-deprecation section
20:18:12 <felixfontein> we also need rules about removing collections I guess. when they start violating rules and don't adjust.
20:18:25 <jillr> abadger1999: that's a really good question, are we considering including collections that aren't f/oss?
20:18:29 <gundalow> #action checklist need an overhaul based on semver, for example the #versioning-and-deprecation section
20:18:41 <dmsimard> felixfontein: to a bigger extent that's probably about enforcing (or verifying) compliance
20:18:49 <felixfontein> dmsimard: yep
20:18:51 <gundalow> wrt CVE I guess we need an email address
20:19:04 <jillr> gundalow: +1
20:19:22 <gundalow> #action Need email address of maintainers for CVEs
20:19:35 <abadger1999> jillr: I think we 100% need to require the license to be floss.  But I hadn't thought about requiring the collection to follow good standards for managing their own community/repo.
20:19:36 <jtanner> what is the recourse if <intern>@megacorp.com doesn't respond to the cve email?
20:20:07 <abadger1999> Right now the only recourse that I know of for non-compliance is that we kick a collection out.
20:20:22 <jtanner> before or after the next major release?
20:20:28 <aminvakil> it's a very good start, but i can't find requirements about unit and/or integration tests? although it should not be mandatory as some modules cannot have integration tests for example, but it will be good to mention it and if it can be handled in some way that should be necessary imho
20:20:29 <dmsimard> felixfontein: ideally most/all checklist requirement compliance would be automated so we can easily validate on a regular basis without burning humans out
20:20:29 <gundalow> #action create issue to track CI testing to match Galaxy/AH import testing
20:20:40 <abadger1999> If we can come up with other recourses we can document them and decide when each is appropriate to apply.
20:21:06 <jillr> jtanner: oh that's interesting, like would be have to do a full deprecation cycle?
20:21:39 <felixfontein> jtanner: we can only remove in a new major version
20:21:46 <felixfontein> otherwise we're violating semver
20:21:52 <jtanner> yeah ... you are all going into semver theory ... does ripping a collection out of a distro without bumping the major comply with semver?
20:22:04 <gundalow> recourses is a different topic
20:22:24 <jillr> gundalow: that's fair, should that be on the agenda next week?
20:22:38 <tadeboro> I feel that repo management stuff is a bit irrelevant as far as the "we want to include high-quality collections" go. Who cares if we have merge commits in our history if our end-result is great?
20:22:41 <gundalow> aminvakil: What would you like to see about unit/sanity tests?
20:23:07 <felixfontein> maybe we should open issues for the various points, so people can already add their opinions there. might speed up the next meetings :)
20:23:17 <jtanner> tadeboro: merge commits are a pita to backport/cherrypick .. it's not just a matter of core devs being picky
20:23:28 <dmsimard> tadeboro: it's also un-enforceable outside of ansible-collections namespace
20:23:38 <aminvakil> gundalow: i'm not sure, but i feel sanity tests alone are not enough.
20:23:45 <felixfontein> jtanner: since we only include the galaxy artefact, we don't care whether they use git at all :)
20:23:46 <tadeboro> jtanner: But I am doing all that, not the community team.
20:24:08 <felixfontein> they can use 3.5" disks as a version control system for what I care about
20:24:19 <jtanner> until you or your sponsor stop funding your projects, then the community team is left holding the responsibility
20:24:24 <jillr> lol felixfontein :)
20:24:31 <gundalow> If we can get a list I'll create a GH discussion with separate comment for each item
20:24:58 <tadeboro> For the record: I also hate merge commits, but that is just my preference.
20:25:00 <gundalow> #action Include strong worded comments about unit tests (module_utils) and integration tests
20:25:07 <gundalow> #chair
20:25:07 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro
20:25:11 <felixfontein> aminvakil: I agree that there should be more tests. for existing content we couldn't really ask that, without commiting to write them ourselves, but for new stuff we can ask for that
20:25:14 <gundalow> What else is missing from the checklist?
20:25:29 <tadeboro> jtanner: If my collection goes unmaintained, it gets kicked out of Ansible and that is it.
20:25:38 <aminvakil> felixfontein: +1
20:25:51 <gundalow> The bar can be continually raised, older content would be grandfathered in, though we can help improve them over time
20:26:04 <felixfontein> tadeboro: people can still manually install the kicked out collection if they really want to use it, so kicking out is not making it impossible to use it anymore
20:26:22 <tadeboro> felixfontein: But at that point, it is not your problem anymore.
20:26:31 <felixfontein> tadeboro: so we shouldn't mind kicking stuff out too quickly :)
20:26:47 * geerlingguy afk for a couple min
20:26:50 <dmsimard> I'd still be wary of /too easily/ kicking collections out
20:26:55 <dmsimard> at the expense of breaking users
20:26:57 <cyberpear> tadeboro: you can configure the tools to just show it as if it were a squash/merge
20:26:58 <gundalow> I think we are going off topic slightly
20:27:19 <felixfontein> dmsimard: I don't think we do, but as opposed to removing content from a collection, removing a collection from ansible can easily be worked around
20:27:42 <jillr> I think there's definitely a conversation to be had around test criteria, but we can have that in a discussion thread probably
20:27:55 <felixfontein> jillr: I think that's a good idea!
20:27:57 <dmsimard> felixfontein: right -- I just mean that whatever recourse we end up with, there should be warnings/attempts at coming back into compliance
20:28:01 <jillr> if the plan is to create threads for these items
20:28:10 <abadger1999> #info https://hackmd.io/4hCPYtfLQQO4O9_UfcfhUQ
20:28:14 <felixfontein> dmsimard: definitely. kicking out is a last resort
20:28:19 <dmsimard> ++
20:28:29 <abadger1999> I haven't added everything that's being discussed here yet.
20:28:51 <felixfontein> who wants to collect the list and create issues?
20:29:06 <dmsimard> afk to pick up kids o/
20:29:17 <felixfontein> let's mention all issues in the community agenda issue, or have a meta issue (whoever creates the issues can decide what they prefer)
20:29:32 <gundalow> felixfontein: I'll do that tomorrow
20:29:34 <felixfontein> and if someone else can think of something that hasn't been mentioned yet, simply create a new issue (and also mention it)
20:29:51 <felixfontein> the next meeting is in two weeks, so there's plenty of time to think about all these things
20:30:16 <felixfontein> does that sound reasonable?
20:30:19 <felixfontein> gundalow: thanks a lot :)
20:30:38 <jillr> felixfontein: sounds good to me
20:30:47 <geerlingguy> felixfontein: two weeks == just enough time for me to realize there's another one of these meetings coming up :D
20:31:11 <felixfontein> :)
20:31:46 <gundalow> Is there anything else, I need to drop off
20:31:57 <abadger1999> One thing:
20:32:16 <abadger1999> When you write up your proposals for changes: please categorize in this way:
20:32:27 <abadger1999> (1) I will not vote to approve the existing checklist without this
20:32:45 <abadger1999> (2) I want to get this change added but it does not block the existing checklist being approved
20:33:51 <felixfontein> I guess you can also add that classification to other people's proposals
20:34:00 <abadger1999> If we have a ton of things in category (1), I think we'll have to go through and re-categorize them so please use that category sparingly.... It's definitely okay not to have any proposed changes that fall into that.
20:35:17 <felixfontein> sounds good to me
20:35:22 <felixfontein> anything else for this topic for today?
20:35:29 <tadeboro> Maybe a bit off-topic, but still: are there any existing content-inclusion requests? Because when I talked to people who intend to start using collections, they will install them manually and possibly keep it pinned down to the exact version that they verified works for them.
20:36:04 <tadeboro> Spending a ton of time and then getting no including requests might be a bit silly.
20:36:13 <felixfontein> if not, I'd propose we spend a little time on https://github.com/ansible/community/issues/539#issuecomment-715496088, since the last c.g 1.x.0 release will happen very soon (i.e. before the next meeting) and the question becomes irrelevant if that passed
20:36:14 <abadger1999> We don't have any publically that I know of.  I asked the internal partner team today and they think there's about ~10 collections that partners will want to get added for 2.11.0
20:36:36 <abadger1999> s2/11/0/3.0.0/  ;-)
20:36:46 <acozine> heh
20:36:48 <felixfontein> tadeboro: there are some plans, like moving the hashi_vault plugin into its own collection, and the hetzner modules too
20:37:05 <abadger1999> I don't know how many community-non-partner collections there are waiting for us to decide on this.
20:37:08 <tadeboro> felixfontein: But those are not new new.
20:37:24 <felixfontein> tadeboro: ah I think I read your question wrong
20:38:24 <tadeboro> felixfontein: I probably wrote it down badly. Getting late in CET ;)
20:38:32 <felixfontein> tadeboro: it is :)
20:38:45 <aminvakil> felixfontein: i think as it seems the original author of issue has not asked about that in a while it's fine to postpone it to the next release.
20:38:52 <felixfontein> community.sops would like to be included in 2.11 :)
20:39:11 <abadger1999> #action ALL: Please write up your proposals for changes to https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst  categorized by whether they should block approval of the checklist or not.  We'll start discussing and voting on changes next meeting
20:39:15 <felixfontein> aminvakil: the next release will be 2.0.0, which accepts breaking changes anyway :)
20:39:54 <felixfontein> #info Reminder: next meeting is in two weeks, i.e. December 2nd, starting at 19:00 UTC
20:39:56 <aminvakil> well let's put it in 2.0.0, i don't think it's worth to discuss it after a 40 minute overdue:)
20:40:06 <felixfontein> aminvakil: fine for me :)
20:40:22 <abadger1999> #action Write your proposals as an issue and mention it in the community agenda ticket https://github.com/ansible/community/issues/539
20:41:47 <abadger1999> Cool.
20:43:06 <felixfontein> ok. open floor?
20:43:12 <abadger1999> +1
20:43:17 <felixfontein> #topic open floor
20:43:24 <felixfontein> does anyone have something for the open floor?
20:43:43 <felixfontein> if yes, quickly say so so we don't close before you finished writing your stuff ;)
20:43:50 <felixfontein> #chair
20:43:50 <zodbot> Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro
20:44:09 <abadger1999> ;-)
20:44:36 <cyberpear> the template should be liberally licensed
20:44:46 <abadger1999> Nothing from me (except sorry for pushing some big discussions onto the agenda at the last minute)
20:45:09 <acozine> better to get them in and get the discussion started
20:45:13 <abadger1999> cyberpear: meaning the templates for a new collection?  I agree
20:45:17 <cyberpear> I opened an issue on the repo, but missed any response
20:45:19 <acozine> we can't start any younger, as they say
20:46:02 <cyberpear> right now if you don't want GPL, you have to invent your own template
20:46:12 <abadger1999> cyberpear: Can you link to that?
20:46:27 <abadger1999> (there's so many repos I can't remember where everything lives)
20:46:38 <felixfontein> https://github.com/ansible-collections/collection_template/issues/18
20:46:53 <cyberpear> https://github.com/ansible-collections/collection_template/issues/18
20:47:02 <felixfontein> I think the license in the repo is meant as the default license for a new collection, not as a license for the template itself
20:47:37 <abadger1999> I think I count 8 contributors.
20:47:38 <cyberpear> we should make it explicit
20:47:44 <tadeboro> cyberpear: It is quite hard to write a non-GPL collection if you have a non-module plugin of any kind.
20:47:45 <felixfontein> if everyone sees it that way, we should clarify that so that we don't prevent people using the template because they don't want to license their collection as GPL
20:48:09 <felixfontein> tadeboro: if you just have roles, playbooks and modules, it's doable :)
20:49:17 <abadger1999> #info need to write some text to explain what license the template is under and what licenses the collection owner can place it under
20:49:27 <felixfontein> abadger1999: I'm not sure what the real intend of the template was, do you agree with my statement that GPL was not meant as a license of the template?
20:49:49 <abadger1999> #info need to CC all of the current contributors (8) to the templates about whether we can license it under a liberal license (3-clause BSD maybe?)
20:50:05 <tadeboro> Is it even possible to license template under a different license from the final (user-provided) content?
20:50:28 <abadger1999> felixfontein: I think it probably doesn't matter what our intentions were :-(   Because it's confusing, we have to get approval from everyone who might have thought they were contributing under the GPL.
20:50:40 <felixfontein> abadger1999: true, but that should be doable :)
20:51:27 <abadger1999> tadeboro: Some licenses allow you to sublicense/embed the code in your own work which is under a different license.
20:51:38 <abadger1999> So  Ithink those are for a template.
20:52:19 <tadeboro> abadger1999: I was thinking more in the context of hosting content on GitHub without confusing the heck out of potential users and/or contributors.
20:53:14 <felixfontein> btw, for repos created from a template, is it possible to remove this `generated from ansible-collections/collection_template` note?
20:53:15 <abadger1999> <nod> Yeah.... there is the potential for high confusion factor.
20:53:41 <samccann> my albeit vague recollection is that the license within the template was an 'example' license... not a license for using the template itself
20:55:04 <abadger1999> who is working on the template?
20:56:08 <felixfontein> abadger1999: everybody and nobody :)
20:56:25 <felixfontein> i.o.w. gundalow ;)
20:56:39 <dericcrago> looks like gundalow has done the most with it - https://github.com/ansible-collections/collection_template/graphs/contributors
20:56:49 <tadeboro> Maybe an "interactive" template (for example, `ansible-galaxy collection init` with a bit more content) would be a better long-term solution?
20:56:52 <samccann> i did some on the readme
20:57:04 <resmo> btw, I added a deprecation with module.deprecate but running collection integration tests, I don't see any message. I also tried module.warn which does show. Is this expected?
20:57:22 <dericcrago> tadeboro - dmsimard had mentioned maybe doing something similar with `cookiecutter`
20:57:29 <samccann> if you look at the 'raw' version of the readme - it has a lot more info in comments.  Something tells me folks aren't doing that tho so maybe that needs to be pulled out and made visible
20:58:03 <felixfontein> resmo: deprecation warnings are only shown the first time, so maybe you didn't look at the right invocation
20:58:09 <felixfontein> resmo: but in general it should show up
20:58:50 <tadeboro> samccann: I was thinking more about the issue with the license. Interactive template can prompt user for a license and then install that while keeping its content licensed however it feels like.
20:59:31 <resmo> felixfontein, I checked but can not find any.
20:59:38 <felixfontein> resmo: url?
20:59:50 <tadeboro> resmo: This is how we check in our integration test for the deprecations: https://github.com/sensu/sensu-go-ansible/pull/230/files
21:00:13 <felixfontein> "We still want to support ansible < 2.9.10" - my condolences :)
21:00:25 <samccann> the existing collection template allows a developer to create the repo will all those bits using github's 'create repo from template' option
21:01:04 <samccann> I dunno `cookiecutter` etc so don't know if it allows for that same repo creation... or if it matters?
21:01:10 <resmo> tadeboro, similar to what I do (also added collection_name, but does not show up with ansible-test integration version 2.11.0.dev0
21:01:28 <resmo> when I switch to warn, I see warnings.
21:01:57 <resmo> let me test with ansible-2.10
21:02:07 <tadeboro> samccann: That is true. But you still need to fill in and replace some things in that template while the cookie-cutter variants can interactively prompt for info.
21:02:19 <felixfontein> maybe ansible-test hides deprecations?
21:02:53 <tadeboro> samccann: But both solutions are fine as far as I am concerned as long as the licensing is not confusing.
21:04:14 <tadeboro> samccann: But I always used "generators" for such things: bison for parsers, molecule uses cookie-cutter, ...
21:05:02 <samccann> given we are 2 hrs into a 1 hr meeting - is there something we can do/decide here? or should we sprinkle some infos and think Deep Thoughts about it all for the next meeting?
21:05:19 <tadeboro> felixfontein: Welcome to the world of enterprise software ;)
21:05:55 <felixfontein> samccann: I think not.
21:05:58 <felixfontein> #endmeeting