18:00:12 <felixfontein> #startmeeting Ansible Community Meeting
18:00:12 <zodbot> Meeting started Wed Apr 14 18:00:12 2021 UTC.
18:00:12 <zodbot> This meeting is logged and archived in a public location.
18:00:12 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:12 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:12 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:12 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping!
18:00:16 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:22 <jillr> o/
18:00:23 * samccann waves
18:00:24 <tadeboro> o/
18:00:24 <dmsimard> \o\
18:00:31 <abadger1999> Hi :-)
18:00:34 <lmodemal> Hello :)
18:00:35 <felixfontein> #chair jillr samccann tadeboro dmsimard abadger1999
18:00:35 <zodbot> Current chairs: abadger1999 dmsimard felixfontein jillr samccann tadeboro
18:00:38 <acozine> sorry, I'm out today - getting my first COVID vaccine jab
18:00:40 <andersson007_> o/
18:00:44 <felixfontein> #chair lmodemal andersson007_
18:00:44 <zodbot> Current chairs: abadger1999 andersson007_ dmsimard felixfontein jillr lmodemal samccann tadeboro
18:00:47 <felixfontein> acozine: congrats! :)
18:00:48 <dmsimard> acozine: congrats and take care
18:00:56 <abadger1999> acozine: congratulations!
18:00:57 <jillr> acozine: hurrah!
18:01:08 <acozine> I'm excited and a little nervous about side effects
18:01:11 <acozine> but mostly really happy
18:01:18 * acozine waves
18:01:22 <lmodemal> Good luck acozine!
18:01:45 <acozine> thanks everybody!
18:02:15 <felixfontein> #topic Updates
18:02:19 <felixfontein> #info No more collections can apply for inclusion in Ansible 4
18:02:19 <felixfontein> #info Deadline for approval of new collections in Ansible 4 is April 26th, i.e. in 12 days
18:02:35 <aminvakil> o/
18:02:45 <felixfontein> #chair aminvakil
18:02:45 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ dmsimard felixfontein jillr lmodemal samccann tadeboro
18:02:52 <dmsimard> Maybe we should do another round of reviews in a review day like last time before the approval deadline
18:03:20 <tadeboro> dmsimard: There is not much happening, so not sure if we can do much.
18:03:45 <tadeboro> Most collection did not even respond to the feedback from the first round of reviews.
18:03:50 <dmsimard> I saw that some collections are moving to semver but I haven't followed up to see if there were other outstanding issues
18:03:53 <abadger1999> :-/
18:04:23 <felixfontein> I think the netapp collections are worth looking at again; I think infoblox also did something, and dellemc also had some changes
18:04:41 <tadeboro> netapp collections are almost there, yes.
18:04:41 <felixfontein> I unfortunately didn't manage to really look at any of them again so far
18:05:18 <dmsimard> any other updates ? gundalow/cybette ?
18:06:01 * dericcrago waves
18:06:13 <felixfontein> #chair dericcrago
18:06:13 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro
18:06:27 <felixfontein> I think the next 4.0.0 alpha is coming up today? tomorrow?
18:06:27 <dmsimard> #info There's Red Hat summit coming up April 27th, there's bound to be Ansible things in it: https://www.redhat.com/en/summit
18:06:52 <nitzmahone> (no need to #chair me) - ansible-core 2.11.0 is still on track to ship end of April
18:06:55 <abadger1999> Yeah, today
18:07:07 <abadger1999> #info ansible-4.0.0a4 coming out today.
18:07:13 <dmsimard> #info ansible-core 2.11.0 is still on track to ship end of April
18:07:17 <dmsimard> thanks nitzmahone
18:07:17 <felixfontein> #info #info No more collections can apply for inclusion in Ansible 4
18:07:17 <felixfontein> #info Deadline for approval of new collections in Ansible 4 is April 26th, i.e. in 12 days
18:07:20 <felixfontein> meh
18:07:21 <felixfontein> #undo
18:07:21 <zodbot> Removing item from minutes: INFO by felixfontein at 18:07:17 : Deadline for approval of new collections in Ansible 4 is April 26th, i.e. in 12 days
18:07:22 <felixfontein> #undo
18:07:22 <zodbot> Removing item from minutes: INFO by felixfontein at 18:07:17 : #info No more collections can apply for inclusion in Ansible 4
18:07:35 <abadger1999> #info likely next ansible-4 prerelease will be ansible-4.0.0beta1 on April 27th
18:07:39 <felixfontein> copy'n'paste fail :)
18:08:13 <samccann> heh
18:10:12 <felixfontein> so, I guess the first topic is by tadeboro on semantic versioning. it's not really that urgent anymore, but I guess it still makes sense to discuss it
18:10:16 <felixfontein> #topic Allow non-semantic versioned collections in Ansible
18:10:16 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/7
18:10:19 <felixfontein> Background: the netapp collections did not use semver (that's now switched)
18:10:22 <felixfontein> Question: do we want to allow such collections? (Right now our requirements say no.)
18:10:31 <cybette> o/ sorry for being late
18:10:36 <felixfontein> #chair cybette
18:10:36 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ cybette dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro
18:10:58 <cybette> (the clock is late, lol)
18:11:05 <dmsimard> cybette: oh the irony haha
18:11:09 <tadeboro> netapp still does not use semver in a strict sense, but it should be good enough for inclusion.
18:11:39 <dmsimard> felixfontein: I would tend to side with "no" here due to how we use semver to control the introduction of breaking/incompatible changes in the aggregate community package
18:12:02 <samccann> what's the not quite semver part of netapp?
18:12:11 <felixfontein> I fully agree, I'm against including any collection which doesn't stick to semver
18:12:24 <tadeboro> They can skip minor versions.
18:12:34 <abadger1999> A lot of our tooling relies on semver to tell about compatibility.  So if semver isn't used, it will cause issues.  We can probably work around most of those by manually fixing ranges of permissible versions but it will be extra work.
18:12:35 <felixfontein> I would even suggest to kick out collections that are actively not using semver (I don't mean accidents, these happen, but intentionally ignoring semver)
18:12:35 <jillr> samccann: they're using year as major versin, month as minor version, and then a patch version
18:13:12 <abadger1999> tadeboro: <nod>  I agree with you that we'll be okay if they're just skipping minor versions.
18:13:15 <dmsimard> abadger1999: +1, it "can" be done manually but I can see it get out of hand if there's too many of them
18:13:33 <tadeboro> netapp now follows semver on a repository level. But unfortunatelly, they host 6 collections in that repo that all share the same tags ...
18:13:44 <felixfontein> yep, skipping minor (or major or patch) versions is fine for me, since that doesn't affect the main guarantees semver gives
18:13:51 <abadger1999> jillr: Hmm.... Do they also make guarantees about compatibility?
18:14:08 <jillr> abadger1999: not sure yet, reading in https://github.com/ansible-collections/netapp/issues/93
18:14:12 <abadger1999> Like, "We will only introduce backwards incompatible changes in our first release of hte year" ?
18:14:23 <felixfontein> abadger1999: so far, no, they deprecate by date and that's it I think
18:14:26 <dmsimard> abadger1999: their reply: https://github.com/ansible-community/community-topics/issues/7#issuecomment-816858851
18:14:32 <tadeboro> netapp stopped using year as major version.
18:14:36 <felixfontein> abadger1999: so whenever a version after a deprecation date is released, it should have breaking changes
18:14:42 <jillr> `We strive to maintain backwards compatibility. If there is a strong enough justification, we will increase the Major release number to indicate a chance of a breaking change.`
18:15:02 <jillr> ah ok, so it looks like they just started with the year (from their old scheme) as the current major versin
18:15:07 <tadeboro> Netapp will stay on 21.x.y from now on until compatibility break.
18:15:08 <abadger1999> <nod>
18:15:13 <dmsimard> jillr: that is my understanding as well
18:15:17 <cybette> cyb-clock chimes: 15 min into the meeting
18:15:33 <abadger1999> Okay, that should be fine as long as our policies remain that we'll accept forward-compatible new features into ansible minor releases.
18:15:38 <tadeboro> All things considered, I gave a thumbs up as ar as the versioning is concerned.
18:16:11 <felixfontein> so with the latest change, netapp is fine I think (or does someone disagree?)
18:16:21 <jillr> yeah I'm +1 what they're doing now
18:16:33 <samccann> +1
18:16:34 <abadger1999> +1
18:16:36 <felixfontein> +1
18:16:37 <samccann> makes sense to me
18:17:01 <dmsimard> +1
18:17:12 <lmodemal> +1
18:17:32 <dericcrago> +1
18:17:41 <andersson007_> +1
18:17:55 <cybette> +1
18:17:59 <tadeboro> +1
18:18:02 <felixfontein> #agreed the versioning aspect of the netapp collections is ok for inclusion with their new versioning system
18:18:25 <tadeboro> OK, I will add more info to the ticket and close it.
18:18:35 <dmsimard> tadeboro: thanks for bringing it up
18:19:10 <felixfontein> I don't think we're done with that ticket yet?
18:19:29 <felixfontein> we only discussed the netapp collection, not the question "Including Ansible Collections that do not follow semantic versioning" in general
18:19:31 <dmsimard> in the sense that we are keeping the rule of required semver ?
18:20:23 <felixfontein> from my POV semantic versioning is (next to licensing) the most important condition for a collection to be included - if that's not satisfied, a collection must not be included
18:20:31 <tadeboro> O, right, I forgot I formulated the issue in a broader way.
18:20:54 <andersson007_> felixfontein: +1
18:21:02 <felixfontein> how are you all feeling about that? is it actually necessary to emphasize this more?
18:21:10 <tadeboro> SO I guess the conslusion is: we still require semver, but netapp's versioning is compatible enough for now.
18:21:30 <abadger1999> A lot of the things we do depends on it.  So I would have to see a compelling example of why a collection cannot use semver to change my mind
18:21:34 <abadger1999> tadeboro: +1
18:21:42 <jillr> +1
18:21:56 <dmsimard> I agree that we should keep the semver requirement.
18:22:00 * gundalow waves
18:22:07 <felixfontein> tadeboro: is not skipping versions actually a requirement for semver? I cannot find it in the rules
18:22:10 <abadger1999> VOTE: We still require semver.  netapp's versioning is considered compatible enough that we accept it as semver for our purposes.
18:22:16 <dmsimard> +1
18:22:21 <felixfontein> #chair gundalow
18:22:21 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro
18:22:23 <abadger1999> Oops, sorry if I jumped the gun.
18:22:36 <tadeboro> semver only talks about incrementng versions IIRC.
18:23:03 <felixfontein> tadeboro: yes, I only found the increasing requirement, but skipping versions also satisfies that one
18:23:18 <tadeboro> And I interpret increment as i++
18:23:32 <dmsimard> i++ is weird with float numbers :p
18:23:52 <felixfontein> dmsimard: strings with two '.' are not floats ;)
18:24:05 <andersson007_> imaginary floats
18:24:07 <dmsimard> I suppose, until YAML thinks it's a float
18:24:19 <felixfontein> tadeboro: you can also increment by two
18:24:29 <felixfontein> dmsimard: if you stick to the semver version format, it will never do that
18:24:45 <felixfontein> that only happens with X.Y style versions
18:24:51 <dmsimard> interesting
18:25:28 <felixfontein> anyway, +1 to abadger1999's, even though I think that netapp actually satisfies semver now
18:25:37 <felixfontein> *vote
18:25:39 <abadger1999> +1
18:25:42 <dericcrago> +1
18:25:44 <jillr> +1
18:25:44 <tadeboro> +1
18:25:45 <andersson007_> +1
18:25:47 <samccann> +1
18:25:53 * dmsimard already voted
18:26:00 <felixfontein> true :)
18:26:07 <cybette> +1
18:26:08 <samccann> heh vote early vote often
18:26:54 <felixfontein> :)
18:27:00 <gundalow> +1
18:27:11 <tadeboro> My search-foo is failing me right now. I canot find a definitive answer about incrementing more that one. And most of the stuff actually talks about bumping things ... ;)
18:27:43 <felixfontein> #agreed We still require semver.  netapp's versioning is considered compatible enough that we accept it as semver for our purposes.
18:28:10 <felixfontein> tadeboro: I cannot find anything either
18:29:21 <gundalow> NetApp is following the "spirit of SemVer", though not the "letter of SemVer", I'm OK with that. And I think it's right that any thing (like NetApp) that doesn't fully match should be reviewed here
18:30:19 <cybette> cyb-clock chimes: 30 min past the hour, and 20 min on topic of allowing non-semver collections
18:30:26 <felixfontein> gundalow: I'm still not convinced that they don't follow the "letter of SemVer". do you have more information on this (I assume you also mean the increases)?
18:31:58 <felixfontein> (but I guess that's something we should discuss after the meeting...)
18:32:04 <felixfontein> #topic Remove Python 2.6 requirement
18:32:04 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/6
18:32:07 <felixfontein> #info Proposal: https://github.com/ansible-collections/overview/pull/165
18:32:07 <github-linkbot> https://github.com/ansible-collections/overview/pull/165 | open, created 2021-04-07T16:50:26Z by abadger: RHEL6 went EOL on November 30, 2020.
18:32:13 <tadeboro> I will write our conclusion and observations into the ticket. We can determine what exactly semver is later.
18:32:18 <felixfontein> tadeboro: thanks!
18:32:30 <jillr> tadeboro++
18:32:30 <zodbot> jillr: Karma for tadeboro changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:32:39 <felixfontein> abadger1999: do you want to say something about this one?
18:33:29 <abadger1999> There's been some discussion in the issue ticket.
18:34:27 <abadger1999> I can be on board with the ideas that felixfontein proposed.
18:35:31 <gundalow> felixfontein: (lag) yes I meant the increases. I'd seem some mention that numbers should only be incremented by one. Though I've not read this in the spec
18:36:06 <felixfontein> I don't use Python 2.6, and I'll try to support it in the collections I'm working on as long as ansible-core supports it (in ansible-test), so in the end I'll be happy with everything we decide
18:36:07 <abadger1999> So if people here agree, I'll  change the guidelines PR to emphasize that python-2.6 is only there to support a distro which isn't even fully supported anymore (RHEL6's python no longer receives fixes for most CVEs, for instance).
18:36:15 <abadger1999> samccann: I think we also need something in the ansible pakcage docs
18:36:39 <felixfontein> IIRC cyberpear was more interested in Python 2.6
18:37:01 * cyberpear arrives late
18:37:02 <abadger1999> samccann: Something to tell end users that despite ansible-core supporting python-2.6, many of the collections that make up ansible do not support python-2.6
18:38:00 <samccann> yeah sounds like a good idea abadger1999
18:38:01 <felixfontein> #chair cyberpear
18:38:01 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro
18:38:31 <abadger1999> Cool, I will get together with you after the meeting to try to determine where and then I can propose some content for you to wordsmith.
18:39:07 <abadger1999> cyberpear: Doe that sound like an okay way forward to you?
18:39:11 <cyberpear> at the very least, I'd want to not purposely break py2.6 w/o a good reason
18:39:17 <cyberpear> but it sounds good as you said it
18:39:34 <cyberpear> *as abadger1999 said it
18:39:52 <abadger1999> cyberpear: I think, even under the current guidelines, individual collections can abandon python-2.6 just because they want to.
18:40:04 <cyberpear> sure
18:40:08 <abadger1999> Okay :-)
18:40:12 <abadger1999> Just making sure :-)
18:40:19 <tadeboro> Since sanity tests still run on python 2.6, removing support for python 2.6 is almost as difficult as making sure code works under python 2.6 ;)
18:40:39 <abadger1999> Heh.  True.
18:40:52 <tadeboro> I know we made sure our collections are sanity-clean on 2.6 just to avoid dealing with 100 lines of ignore entries.
18:40:57 <bcoca> insanity tests!
18:41:02 <abadger1999> Okay, if there' sno objections, I'll make updates to these PRs for next week.
18:41:13 <tadeboro> +1
18:41:24 <jillr> all of the cloud collections will be dropping py2 support in the next few months, so we'll need to figure out how to make sanity tests work regardless
18:41:55 <felixfontein> abadger1999: sounds good to me
18:42:06 <felixfontein> jillr: you'll need to add a huge amount of ignore.txt entries :)
18:42:35 <gundalow> jillr: FYI you can run `ansible-test (sanity|integration)` with `--python` to only run on specified versions, not all. Making Galaxy/AH happy is more work. https://github.com/ansible-collections/community.ciscosmb/pull/27/commits/831e5ae48de5ee291e121f9a611f2e006d497126
18:42:44 <tadeboro> I was hoping ansible-test config would materialize a bit sooner, but I cannot complain since I did not contribute anything yet.
18:43:39 <jillr> gundalow: we already have it working for our regular CI, but it sounded like there's 2.6 testing in the package build?
18:44:06 <tadeboro> jillr: AH import runs sanity tests with no --python flags.
18:44:25 <tadeboro> This is the sole reason we made sure our 2.6 sanity is clean.
18:44:28 <felixfontein> gundalow: that way, `ansible-test sanity --docker -v` will fail on the collection
18:44:52 <gundalow> ah, gotcha
18:45:07 <felixfontein> the only clean way for 2.9, 2.10 and 2.11 is to add ignore.txt entries
18:45:08 <cyberpear> (py2.6 is only important for modules that manage a linux distro that might have py2.6... cloud modules need only work on whatever is supported for the controller, IMO.)
18:45:10 <jillr> we already have one 3-only collection, I'm not worried about AH. so it sounded like there was something else checking for 2.6, thus I assumed it was the package build
18:45:16 <cybette> cyb-clock chimes: 45 min into the meeting, and 13 min on topic "Remove Python 2.6 requirement"
18:45:49 <felixfontein> dmsimard: do you want to discuss LTS again today?
18:45:54 <dmsimard> yes
18:46:05 <felixfontein> ok :) then let's do that next
18:46:19 <felixfontein> I think about 2.6 we'll wait til next week for abadger1999's update
18:46:22 <felixfontein> #topic What are the implications of maintaining and supporting past major releases of the ansible package
18:46:25 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/1
18:46:28 <felixfontein> #info writeup: https://hackmd.io/plQlGzcFRFGLnPXIeg3cwQ
18:46:59 <dmsimard> It is not easy to condense everything into a one liner that everyone can vote on so I have put a summary at the bottom which I will paste here for posterity
18:47:20 <dmsimard> > There are benefits to a longer maintenance cycle and while we are open to the idea, it is a non-negligible amount of work without even considering the implications of patching collections that do not backport bug and security fixes.
18:47:32 <dmsimard> > Maintaining a single major version of the ansible package for six months while providing the ability to install and update collections out-of-band leveraging ansible-core and ansible-galaxy is likely a good middle ground until the need for a longer maintenance cycle is voiced by the wider community.
18:49:13 <dmsimard> Does that make sense ? In essence, we are leaving the door opened because we are not against the idea. This packaging and versioning we are using is still relatively young and we can revisit this later if people feel we really need it.
18:50:07 <andersson007_> sounds sensible
18:50:45 <samccann> yeah makes sense. Keep things as is for a few more releases and see how much (if any) demand surfaces for longer maintenance cycles.
18:50:58 <felixfontein> the problem with installing manually with ansible-galaxy is that once you installed a collection manually, installing a newer Ansible version does not overwrite that collection anymore
18:51:22 <felixfontein> which is probably not what a random user (who didn't read the instructions too carefully) expects
18:51:36 <dmsimard> felixfontein: do you think that is fixable ? I'm not familiar enough with these waters
18:51:47 <abadger1999> I like leaving the door open but not committing to doing it without someone from the community who wants to work out the problems and drive it forward.
18:52:13 <abadger1999> dmsimard: It's not really fixable because it was a design decision at the core leel.  (I pretty much agree with the decision too)
18:52:44 <dmsimard> abadger1999: because it's two different paths ? i.e /usr/lib/python vs ~/.ansible/ansible_collections
18:52:53 <nitzmahone> to clarify: it's not that the collection isn't updated, but a collection explicitly installed in any of the user collection paths will mask one installed at the system/PythonLib level
18:53:00 <abadger1999> It's similar to how if you have both an rpm install of ansible and a pip install --user ansible, the pip installed one will always take precedence
18:53:08 <dmsimard> ah, right
18:53:24 <abadger1999> dmsimard: yeah, two different paths.
18:54:15 <cyberpear> though, if someone did `pip install --user ansible` but sysadmin installed a system-wide collection, the system-wide would rule
18:54:15 <felixfontein> TBH I'm not sure at all how to improve on this situation, except documenting it better (though I guess some people will still not notice) and not recommending to use `ansible-galaxy collection install` for collections included in Ansible (which is not compatible with the open door :) )
18:54:47 <cyberpear> probably can't do much better than warning about this case if we can detect it
18:55:25 <andersson007_> we definitely should put  in the collection readmes a note about manual updating
18:55:34 <abadger1999> cyberpear: Hmm... That depends, right?  if the systemwide one was installed into %{python_sitelib}/ansible_collections, then the --user one would rule?
18:55:41 <dmsimard> felixfontein: so to make sure I get this right, would uninstalling the ansible package before installing ansible-core and collections works ?
18:55:50 <nitzmahone> It's not necessarily even something that's warning-worthy- it's an expected and supported scenario
18:55:53 <cyberpear> abadger1999: if the system-wide one is in /etc/ansible...
18:56:06 <abadger1999> cyberpear: yeah.  Just two different use cases.
18:56:20 <cyberpear> abadger1999: you're correct in that case, the user wolud override the one included w/ system-wide ansible package, but not system-wide standalone collections
18:56:22 <felixfontein> dmsimard: depends what you mean by 'works' :)
18:56:26 <nitzmahone> roughly analogous to `sudo pip install foo` and `pip install --user foo`
18:57:00 <dmsimard> felixfontein: well, I mean you shouldn't run into unexpected precedence issues if the ansible package is gone
18:57:01 <nitzmahone> The fact that someone has done the latter doesn't generate a warning from the former- it's completely legit
18:57:25 <dmsimard> nitzmahone: makes sense
18:57:48 <felixfontein> dmsimard: depends on where else they installed things ;) if they have the same collection (with different versions) in the system-wide collections folder and the user collection folder, they have the same problem
18:58:20 <dmsimard> sure, but people get confused about that all the time with just python dependencies across different interpreters anyway
18:58:20 <felixfontein> right now the only way to find out is to run `ansible-galaxy collection list` and look for collections that show up more than once
18:59:28 * samccann needs to drop for another meeting
18:59:33 <samccann> #unchair samccann
18:59:33 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal tadeboro
19:00:12 * lmodemal hard stop at 3pm.
19:00:23 <dmsimard> as an action item, should we vote ? do we keep the issue opened ?
19:00:26 <cybette> cyb-clock chimes: 1 HOUR into the meeting, and 14 min on topic "To LTS or not to LTS"
19:00:27 <lmodemal> See you all next week!
19:00:34 <cybette> see you lmodemal
19:00:53 <felixfontein> bye lmodemal!
19:01:02 <felixfontein> and bye samccann!
19:01:13 <lmodemal> :)
19:01:29 <tadeboro> I think we should vote for "do nothing now and revisit this topic after a few releases".
19:01:35 <abadger1999> Probably (1) Some sort of vote that we're not planning on making an LTS right now. (2) Move your document into the github repo (or community docsite) somewhere.
19:01:36 <felixfontein> dmsimard: vote on what exactly?
19:02:12 <dmsimard> felixfontein: abadger1999's #1 and tadeboro :)
19:02:19 <abadger1999> Also mention the outcome in the bullhorn since we were talking more positively about doing an LTS at contributor summit
19:02:19 <apple4ever> This starts at 2 Eastern now?
19:02:39 <cyberpear> I'd say punt on LTS until we have a breaking release of ansible-core that leaves some folks out in the cold
19:02:43 <dericcrago> apple4ever - yes
19:02:47 <dmsimard> apple4ever: it was moved an hour earlier after DST changes to accomodate later hour in EMEA/APAC
19:02:48 <felixfontein> #chair apple4ever
19:02:48 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ apple4ever cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal tadeboro
19:03:02 <apple4ever> Ah shoot I didn't know. Well I'll update my reminder thanks.
19:03:23 * cyberpear has to jump to another meeting, will keep half an eye here
19:03:34 <felixfontein> cyberpear: every 'major' ansible-core release is breaking someone ;)
19:03:53 <cyberpear> say, one that drops support for a particular python
19:04:11 <felixfontein> apple4ever: if you subscribe to https://github.com/ansible/community/issues/539 you will find out ;) (it's a lot less spammy now as well)
19:04:20 <dmsimard> VOTE: No plan for a LTS maintenance release for the Ansible community package for now, anyone from the community can bring the topic up again for discussion at a later release and we can revisit the topic
19:04:28 <felixfontein> +1
19:04:32 <dmsimard> +1
19:04:35 <andersson007_> +1
19:04:35 <gundalow> +1
19:04:37 <abadger1999> +1
19:04:42 <tadeboro> +1
19:04:43 <aminvakil> +1
19:04:43 <jillr> +1
19:04:50 <cybette> +1
19:05:21 <dericcrago> +1
19:05:45 <felixfontein> #agreed No plan for a LTS maintenance release for the Ansible community package for now, anyone from the community can bring the topic up again for discussion at a later release and we can revisit the topic
19:05:59 <dmsimard> I will take the action of writing something up in the bullhorn about it
19:06:12 <felixfontein> dmsimard: thanks a lot!
19:06:20 <dmsimard> #action dmsimard to write a summary of the LTS discussion in the bullhorn
19:06:24 <felixfontein> #topic open floor
19:06:36 <felixfontein> since we're already at over one hour, let's continue with open floor
19:06:44 <felixfontein> does anyone have something that should be discussed today and wasn't covered yet?
19:08:05 <dmsimard> Somewhat off topic but I just want to plug that ara 1.5.6 is in release candidate and should be released tomorrow, it's been ~2 months in the making and has a significant UI refresh :)
19:08:16 <dmsimard> If you want to check it out, the live demo is up to date: https://demo.recordsansible.org/
19:08:20 <gundalow> Nothing else from me
19:08:28 * dmsimard is in HTML overdose
19:08:49 <cybette> dmsimard: looking cool!
19:09:13 <cyberpear> dmsimard++ thanks for doing ara!
19:09:14 <zodbot> cyberpear: Karma for dmsimard changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:09:32 <dmsimard> cyberpear: I'll probably have something about it for the bullhorn, will add it to the issue
19:09:40 <dmsimard> er, cybette ^
19:09:44 <cybette> :D
19:09:53 <dmsimard> too many similar characters for my autocomplete
19:11:13 <felixfontein> hehe :)
19:11:21 <felixfontein> happens a lot I think ;)
19:11:32 <abadger1999> Cool :-)
19:12:19 <felixfontein> I guess it's time for closing the meeting then?
19:12:24 <dmsimard> +1
19:12:46 <felixfontein> #endmeeting