19:00:12 <felixfontein> #startmeeting Ansible Community Meeting
19:00:12 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
19: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!
19:00:12 <zodbot> Meeting started Wed Feb 17 19:00:12 2021 UTC.
19:00:12 <zodbot> This meeting is logged and archived in a public location.
19:00:12 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:12 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:28 * dericcrago waves
19:00:33 <felixfontein> #chair dericcrago
19:00:33 <zodbot> Current chairs: dericcrago felixfontein
19:00:35 <tadeboro> o/
19:00:36 <andersson007_> o/
19:00:38 <cybette> o/
19:00:41 <felixfontein> #chair andersson007_ cybette
19:00:41 <zodbot> Current chairs: andersson007_ cybette dericcrago felixfontein
19:00:44 <briantist> o/
19:00:46 <lmodemal> Hello o/ - Hard stop at 3pm today :)
19:00:47 <jillr> o/
19:01:13 <briantist> as usual I'm in another meeting and distracted 🤷‍♂️
19:01:42 <felixfontein> #chair briantist lmodemal jillr
19:01:42 <zodbot> Current chairs: andersson007_ briantist cybette dericcrago felixfontein jillr lmodemal
19:01:54 <samccann> only half here. Found a problem w/ the docsite split I need to dig into
19:01:59 <felixfontein> #chair samccann
19:01:59 <zodbot> Current chairs: andersson007_ briantist cybette dericcrago felixfontein jillr lmodemal samccann
19:02:03 <felixfontein> #topic Updates
19:02:03 <felixfontein> #info The docsite split PR has been merged to ansible/ansible's devel branch
19:02:04 <abadger1999> Hello!
19:02:06 <felixfontein> #info We are on target to have two blog posts published Thursday for the 3.0.0 release. One is story-oriented (how we got here) and the other is in a Q&A format to answer some of the questions we have seen so far.
19:02:10 <felixfontein> #chair abadger1999
19:02:10 <zodbot> Current chairs: abadger1999 andersson007_ briantist cybette dericcrago felixfontein jillr lmodemal samccann
19:02:21 <cybette> #info Register for Ansible Contributor Summit 2021.03 https://www.eventbrite.com/e/ansible-contributor-summit-202103-registration-141735886853?aff=irc
19:02:23 * tadeboro waves harder ;)
19:02:27 <cybette> #info Propose topics for Contributor Summit https://hackmd.io/uZDSLOOdS1Kx0xfZVIATmQ
19:02:41 <abadger1999> #chair tadeboro
19:02:41 <zodbot> Current chairs: abadger1999 andersson007_ briantist cybette dericcrago felixfontein jillr lmodemal samccann tadeboro
19:02:42 <felixfontein> #chair tadeboro
19:02:42 <zodbot> Current chairs: abadger1999 andersson007_ briantist cybette dericcrago felixfontein jillr lmodemal samccann tadeboro
19:02:52 <felixfontein> tadeboro: oh, I missed you! sorry!!!
19:03:10 <cybette> now tadeboro has 2 chairs :)
19:03:12 <felixfontein> I was switching too much between brower windows, tabs and IRC windows...
19:03:19 <felixfontein> king of furniture ;)
19:04:47 <acozine> o/
19:04:52 <felixfontein> #chair acozine
19:04:52 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cybette dericcrago felixfontein jillr lmodemal samccann tadeboro
19:05:14 <tadeboro> Oh yeah ;)
19:06:07 <felixfontein> I guess as a first topic we can start with a docs clarification PR:
19:06:07 <felixfontein> #topic Clarity of documentation: https://github.com/ansible-collections/overview/pull/152
19:06:07 <github-linkbot> https://github.com/ansible-collections/overview/pull/152 | open, created 2021-01-27T20:17:20Z by dmsimard: Improve clarity of the documentation requirements
19:06:35 <felixfontein> I think the PR is ready except one suggestion by acozine, which I think is ok in its current version
19:06:35 * gundalow waves
19:06:52 <felixfontein> #chair gundalow
19:06:52 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cybette dericcrago felixfontein gundalow jillr lmodemal samccann tadeboro
19:07:16 <acozine> I updated my comment on PR 152
19:07:36 <acozine> I think it now makes clear that not everything needs `version_added`, esp. in new collections
19:07:58 <acozine> https://github.com/ansible-collections/overview/pull/152#discussion_r574049956
19:07:58 <felixfontein> if you think that https://github.com/ansible-collections/overview/pull/152/files#r574049956 needs more changes, please say so in the next few minutes, otherwise I'll merge that suggestion :)
19:08:12 <felixfontein> s/merge/commit/
19:09:08 <acozine> +1 on the PR in general
19:09:22 <andersson007_> +1 looks good
19:09:23 <abadger1999> +1 to the PR (and suggestion) from me too
19:09:39 <lmodemal> +1
19:09:46 <jillr> +1 overall as well
19:09:53 <dericcrago> +1
19:10:05 <felixfontein> I committed the suggestion, let's properly vote on the PR :)
19:10:13 <acozine> heh
19:10:13 <felixfontein> VOTE: should we merge https://github.com/ansible-collections/overview/pull/152 ?
19:10:16 <acozine> +1
19:10:19 <andersson007_> +1
19:10:21 <jillr> +1
19:10:23 <lmodemal> +1
19:10:25 <cybette> +1
19:10:27 <felixfontein> +1
19:10:31 <tadeboro> +1
19:10:36 <gundalow> +1
19:11:26 <felixfontein> I guess that's it
19:11:30 <abadger1999> +1
19:11:31 <felixfontein> #agreed merge https://github.com/ansible-collections/overview/pull/152
19:11:35 <felixfontein> thanks!
19:11:44 <felixfontein> if we continue with this speed, this will be a short meeting ;)
19:12:14 <felixfontein> does someone has something urgent to discuss / present? otherwise I'd suggest to continue (or properly start?) the discussion on Python version requirements for module_utils
19:13:22 <gundalow> #topic Staffing update
19:13:37 <gundalow> #info Please welcome andersson007_ to the Ansible Community Engineering Team
19:13:51 <felixfontein> ah right :)
19:13:54 <dericcrago> welcome andersson007_!
19:13:55 <cybette> welcome andersson007_ !
19:13:56 <felixfontein> welcome andersson007_!
19:14:00 <andersson007_> gundalow and everyone, thanks!
19:14:08 <gundalow> (as I missed the updates bit at the start of the meeting)
19:14:26 <felixfontein> andersson007_: I guess we'll see you more often in this meeting from now on ;)
19:14:28 <gundalow> what's next topic, Python module_utils?
19:14:31 <lmodemal> Welcome andersson007_!
19:14:37 <felixfontein> gundalow: I think so
19:14:38 <andersson007_> yes felixfontein :)
19:14:41 <felixfontein> #topic Python version requirements for module_utils
19:15:04 <felixfontein> we already talked a lot about Python version requirements last week
19:15:20 <felixfontein> a good summary (including the votes from last week) can be found here:
19:15:23 <felixfontein> #info https://github.com/ansible-collections/overview/pull/151#issuecomment-777654599
19:15:23 <github-linkbot> https://github.com/ansible-collections/overview/pull/151#issuecomment-777654599 | open, created 2021-01-25T12:48:11Z by Ompragash: New Policy Regarding Python Compatibility for Collections
19:16:35 <abadger1999> module_utils seems like the hardest of the three remaining questions.  There isn't a bright line to guide it.
19:16:45 <felixfontein> the two remaining questions are a) which versions do we require as a minimum for controller-side and remote-side, and b) what do we require for module_utils in collections that are only controller-side?
19:17:12 <felixfontein> abadger1999: what's the third question?
19:17:26 <abadger1999> And a.2) What determines when we update the minimum controller-side and remote-side versions
19:17:43 <felixfontein> ah right!
19:18:14 <felixfontein> should we talk about concrete versions first (and when to update them), or about module_utils?
19:18:31 <abadger1999> Sure.  Low hanging fruit, right? ;-)
19:19:27 <abadger1999> #topic Minimum versions of Python for controller-side and remote-side
19:20:43 <felixfontein> IMO for Ansible versions based on ansible-core 2.10 and 2.11, we should stick closely to the ranges defined by Ansible itself - which are 2.6+ for remote-side and 2.7+ for controller-side
19:21:09 <abadger1999> +1
19:21:13 <felixfontein> (ansible-core 2.11 contains a deprecation message for Python < 3.8 on controller-side, but the removal is scheduled for ansible-core 2.12, so 2.11 still supports them)
19:21:56 <cybette> cybette-clock says: we're 21 minutes into the meeting!
19:21:59 <felixfontein> I personally find it acceptable if collections want to drop Python 2.6 support, but I don't like the idea of dropping 2.7 support (assuming the collection does not depend on some library which has higher version requirements)
19:22:45 <felixfontein> I think the exclusion rule for when used libraries require newer Python versions is ok for everyone (if not - please say so!)
19:23:03 <acozine> are there OSs/distros that install 2.6 by default? would we be excluding those if we allow dropping 2.6? (I'm not against this, just thinking we need to document it if that's the case)
19:23:37 <abadger1999> I'd also like us to think about dropping required remote-side python versions in terms of dropping support for managing certain remote platforms.  So, for instance, if we're willing to drop Python-2.6 and Python-3.5, we should be thinking of it as dropping RHEL6 and Ubuntu-(14.04?) support.
19:23:51 <jillr> acozine: rhel6
19:23:53 <felixfontein> RHEL6 comes with Python 2.6 by default, and Ubuntu 16.04 (?) comes with Python 3.5 by default (and no Python 2, but that can be installed)
19:24:07 <tadeboro> I would say that we set the lower bound on what Ansible 2.9 defines since that version is not going anywhere anytime soon. And while collections might be primarily concerned about what is part of ansible >= 3 package, users might still want to install them manually.
19:24:58 <felixfontein> tadeboro: that's true, though we have rules for inclusion in Ansible 4.0.0+, and supporting Ansible 2.9 has never been part of these rules :)
19:25:33 <felixfontein> I guess there are two parts: a) things we wish, and b) things we absolutely require
19:25:34 <tadeboro> This is why I added that second part of my argument.
19:25:38 <briantist> going to re-state felixfontein 's assertion/question, as it applies directly to my collection 😅: `I think the exclusion rule for when used libraries require newer Python versions is ok for everyone (if not - please say so!)`
19:26:21 <abadger1999> tadeboro: Do we want to be in the business of pushing collections to be compatible with ansible-2.9 or do we want to leave that up to individual collections?
19:26:48 <abadger1999> Exclusions rule for libraries is definitely okay for me.
19:26:53 <felixfontein> I think we should not require collections to support Ansible 2.9. it's nice if they do, and we can recommend they should try to, but I don't think we should require them
19:28:19 <tadeboro> I agree with felixfontein on this one: 2.9 compatibility is nice-to-have. And until 2.12, things are not problematic.
19:29:02 <tadeboro> Although I think sivel or mattclay mentioned something about ansible dropping python 2.6 compatibility in the future.
19:29:20 <sivel> yeah, that is early discussions, don't worry quite yet about it
19:29:59 <sivel> I'm guesstimating that it likely would not happen until 2.13, but with the limited conversations we've had, it's hard to say exactly
19:30:21 <cybette> cybette-clock says: we're at 11 min for topic "Minimum versions of Python for controller-side and remote-side", and 30 min into the meeting
19:30:27 <felixfontein> so it won't affect us until Ansible 6, which is next year
19:30:44 <felixfontein> (assuming everything progresses as now :) )
19:31:21 <jillr> Is the idea then that we largely tie supported pythons for collections to ansible-core; so for now 2.6+ for remotes, and then as the core that ships with an ansible release drops pythons the collections can too?
19:31:44 <felixfontein> do we want to allow collections to skip Python version support for a limited set even if the libraries they use support them?
19:31:50 <felixfontein> jillr: sounds reasonable to me!
19:31:55 <tadeboro> I would vote for "define compatibility with whatever ansible uses as a base" and for adding "supporting 2. is nice because this is what one can buy support for".
19:32:08 <tadeboro> s/2./2.9/
19:32:35 <abadger1999> I think I could make a proposal for the controllerside.  Except that we voted a few weeks ago on allowing collections to drop python3.5 support.  Do we want that to stay in or do we want to get rid of that allowance?
19:32:36 <jillr> felixfontein: and it gives us a good reference framework for what should be supported at each release
19:32:45 <felixfontein> tadeboro: 2.6? 2.7?
19:33:15 <felixfontein> personally for me, I think it is ok for collections to drop 2.6 and 3.5 support if they properly document that
19:33:30 <felixfontein> I would require 2.7 and 3.6+ support though (assuming required libraries support that)
19:33:46 <tadeboro> felixfontein: My versions are ansible versions ;)
19:33:51 <felixfontein> we should recommend to support 2.6 and 3.5 as well
19:33:54 <felixfontein> tadeboro: ah, sorry :D
19:35:59 <tadeboro> So, I vote for 2.6 and 3.5 on remote if at all possible, 2.7 and 3.6+ always on remote; and 2.7+ on controller-side.
19:36:35 <felixfontein> tadeboro: also 2.7+ and 3.6+ on controller side?
19:36:42 <felixfontein> or 2.7+ and 3.5+?
19:37:52 <tadeboro> Hmm, I am not sure if ansible-base supports 3.5 on control node. If the answer is yes, then I would say 3.5 is included in my 2.7+.
19:38:22 <abadger1999> Yeah, the python3 requirement is the same controller and remote side for anible-base
19:38:26 <felixfontein> PROPOSAL 1: require 2.7 and 3.6+ support both for remote-side and controller-side, and suggest to also support 2.6 on remote-side and 3.5 on both sides (always assuming required libraries support this)
19:38:29 <abadger1999> (until ansible-2.12)
19:38:31 <felixfontein> tadeboro: I think it does
19:38:48 <abadger1999> +1
19:39:02 <tadeboro> That proposal works for me, yes.
19:39:02 <felixfontein> PROPOSAL 2: require 2.7 and 3.5+ support both for remote-side and controller-side, and require 2.6 support on remote-side (always assuming required libraries support this)
19:39:15 <felixfontein> does anyone would prefer yet another proposal?
19:40:25 <cybette> cybette-clock says: we're at 21 min for topic "Minimum versions of Python for controller-side and remote-side", and 40 min into the meeting
19:40:29 <abadger1999> I'm +1 to either of those.  I prefer Proposal 2 but Proposal 1 incorporates the results of the vote that occurred a few weeks ago.
19:40:33 <felixfontein> PROPOSAL 1 == making 2.6 and 3.5 support optional, PROPOSAL 2 == requiring 2.6 and 3.5 support if there are no good reasons (like library support)
19:41:10 <felixfontein> as abadger1999 said we already agreed on PROPOSAL 1 once. does anyone wants another vote (because they changed their mind, or think that some others changed their mind)?
19:41:16 <jillr> I prefer Proposal 1, but I wouldn't block on Proposal 2
19:41:36 <felixfontein> if not, we should keep proposal 1 and discuss on when to increase the lower bounds
19:41:45 <acozine> purely on the grounds that it's easier to describe, i prefer proposal 1
19:42:03 <felixfontein> I guess the proposal for that would be: The minimal bounds are adjusted when ansible-core drops support on remote and controller side for specific Python versions
19:42:25 <abadger1999> Yeah, but we have to be careful about the word "support"
19:42:49 <abadger1999> Maybe, when ansible-core will no longer run for a specific python version
19:43:08 <felixfontein> that would be what I mean with support, so +1 for that formulation :)
19:43:15 <felixfontein> I guess we agree to keep proposal 1 then
19:43:35 <felixfontein> #agreed We keep our previous voted on proposal: require 2.7 and 3.6+ support both for remote-side and controller-side, and suggest to also support 2.6 on remote-side and 3.5 on both sides (always assuming required libraries support this)
19:43:57 <acozine> w00t!
19:44:07 <felixfontein> Proposal: The minimal bounds are adjusted when ansible-core stops running on specific Python versions on remote or controller side
19:44:12 <abadger1999> +1
19:44:15 <felixfontein> does that sound reasonable?
19:44:18 <abadger1999> Oh
19:44:19 <jillr> +1
19:44:36 <abadger1999> [..] when the ansible-core we depend on stops running [...]
19:44:56 <jillr> ah good addition, +1
19:45:00 <acozine> mm, yep
19:45:03 <felixfontein> so for Ansible based on ansible-core 2.12 we require 3.8+ for controller-side, and and for Ansible based on ansible-core 2.13 we require 2.7+ for remote-side (assuming that happens for 2.13)
19:45:25 <felixfontein> Proposal: The minimal bounds are adjusted when the ansible-core we depend on stops running on specific Python versions on remote or controller side
19:45:34 <abadger1999> +1
19:45:36 <felixfontein> (with abadger1999's improvement)
19:46:02 <felixfontein> and I guess we can decide to make other Python versions optional that ansible-core runs on later as well
19:46:20 <acozine> +1
19:46:33 <felixfontein> but that shouldn't happen automatically, it would require a discussion and a vote
19:47:00 <abadger1999> sounds good to me
19:47:48 <abadger1999> Anyone else want to vote on this proposal?
19:47:52 <abadger1999> #chair
19:47:52 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cybette dericcrago felixfontein gundalow jillr lmodemal samccann tadeboro
19:47:56 <lmodemal> +1
19:48:02 <felixfontein> VOTE: The minimal bounds are adjusted when the ansible-core we depend on stops running on specific Python versions on remote or controller side
19:48:03 <tadeboro> +1
19:48:05 <felixfontein> +1
19:48:12 <briantist> +1
19:48:14 <andersson007_> +1
19:48:15 <abadger1999> +1
19:48:18 <jillr> +1
19:48:19 <lmodemal> +1
19:49:12 <felixfontein> #agreed The minimal bounds are adjusted when the ansible-core we depend on stops running on specific Python versions on remote or controller side
19:49:20 <felixfontein> great :)
19:49:42 <abadger1999> I have one time-sensitive thing I should ask before we look at module_utils
19:49:51 <felixfontein> +1
19:50:12 <abadger1999> #topic Any blockers for ansible-3.0.0 tomorrow?
19:50:19 <felixfontein> ah right :)
19:50:25 <abadger1999> I'm going to release ansible-3.0.0 tomorrow.
19:50:32 <cybette> cybette-clock says: we're 50 min into the meeting
19:50:41 <felixfontein> samccann: how does the docsite split looks? are you resp. the WIP backport ready to handle 3.0.0?
19:50:43 <abadger1999> This is a last call for anyone to holler stop if they know of any blockers
19:51:32 <acozine> we can cobble together something for docs
19:51:34 <felixfontein> I think the docsite split is the only potential blocker we have, since from how I understood dmsimard the blog posts will be ready
19:51:46 <abadger1999> Yep.
19:52:17 <acozine> we've got some failures on the backport, and the version-switcher is wonky on the `ansible-core` docs, but we can fudge that if absolutely necessary
19:52:29 <abadger1999> acozine: Okay, cool :-)
19:52:35 <acozine> I don't think we need to hold the release
19:52:55 <acozine> but we may need a little backup early next week to get everything cleaned up
19:53:07 <abadger1999> #info docsite split should be okay for tomorrow.  There is some failures on backport and wonkiness in the version-switcher but those do not need to block release.
19:53:21 <abadger1999> #info dmsimard's blog post for 3.0.0 is ready
19:53:36 <abadger1999> #info No blockers for release; ansible-3.0.0 will go out tomorrow!
19:53:58 <abadger1999> felixfontein: Okay, nothing more from me on this topic
19:53:59 <gundalow> The blog post should be published tomorrow. We will include links in the release announcement
19:54:12 <cybette> and bullhorn etc.
19:54:29 <felixfontein> great! :)
19:54:43 <felixfontein> ok, so let's go back to module_utils
19:54:44 <felixfontein> #topic Python version requirements for module_utils
19:55:15 <felixfontein> module_utils are generally remote-side, but it could happen that a collection only has controller-side modules (think of network collections) and thus doesn't want to support Python 2.6 in module_utils
19:55:33 <felixfontein> on the other hand, other collections that are not controller-side only could depend on this collection's module_utils
19:56:09 <abadger1999> Yeah, the latter is what makes this problematic.
19:56:42 <felixfontein> I'm personally ok for collections to declare their module_utils controller-side only if they announce it early enough and well enough (so that it is hard to miss)
19:57:36 <abadger1999> How do we make it hard to miss?
19:57:37 <jillr> we only require 2.7+ support now, we just recommend 2.6. so we could do the same for module_utils
19:57:40 <felixfontein> for collections that are known to be used by other collections (like ansible.netcommon), I would expect this to be announced in https://github.com/ansible-collections/overview/issues/45 and The Bullhorn
19:57:47 <tadeboro> The announcement part is problematic here.
19:58:03 <felixfontein> for collections that are not aware of any user, I think it's fine if they announce it in their changelog
19:58:10 <felixfontein> tadeboro: definitely!
19:59:43 <abadger1999> It feels like it should be in some sort of non-time-specific docs too.  Unfortunately, module_utils  are often undocumented.
20:00:40 <cybette> cybette-clock says: we're 6 min in topic "Python version requirements for module_utils", and 1 HOUR into the meeting
20:01:26 <tadeboro> Since users already need to dig through the code because there is no docs for things in module_utils, maybe adding a note at the top of the file would do?
20:01:48 <felixfontein> out of curiosity, does anyone think that module_utils must always support all remote-side Python versions (except the allowed exceptions, i.e. 2.6 and 3.5 at the moment)?
20:02:26 <tadeboro> I am against this because of things like modules that use httpapi and are fixe to localhost.
20:02:26 <felixfontein> tadeboro: you mean the users should create a PR for the collection they use and add a notice at the top of the files they use that this file is used by their collection?
20:03:00 <felixfontein> tadeboro: I think I am too, but it would be interesting to know of someone disagrees and wants to always require this
20:03:04 <tadeboro> felixfontein: No, what I mean to say that collection author should declare python compatibility of source files.
20:03:34 <abadger1999> felixfontein: That's not my ideal but I'd rather that than people thinking they can use something on the remote side but it turns out to drop remote-side python-version  support later.
20:03:49 <felixfontein> tadeboro: ah, ok. but we still need a mechanism to find out when they change :)
20:04:08 <tadeboro> Yep, that is still problematic.
20:04:44 <abadger1999> +1 to tadeboro's suggestion to document "this module_utils is for controller-side use only" in the top of the file.
20:04:44 <tadeboro> But this should cover the abadger1999's concern of having things documented in a non-time-dependent fashion.
20:04:49 <abadger1999> Maybe a toplevel docstring.
20:05:06 <abadger1999> python docstring in case that was ambiguous.
20:05:12 <felixfontein> :)
20:05:38 <jillr> I like the idea of docstrings in module_utils detailing supported pythons, usages, etc
20:05:40 <felixfontein> so we have: Proposal: module_utils in a collection have to document the supported Python versions at the top of every file in a docstring
20:06:26 <briantist> that sounds good but I hope this requirement comes with an example in the docs around module_utils
20:06:28 <abadger1999> Maybe only if they vary from the recommendations/requirements.
20:06:54 <abadger1999> And maybe "controller-side only" is a good shorthand to list as well.
20:07:04 <felixfontein> abadger1999: good points
20:07:25 <abadger1999> (that way a collection author doesn't have to update all the docstrings when the overall controller-side compat is changed)
20:07:56 <felixfontein> so a) no docstring = everything we recommend for remote-side is supported, b) docstring 'controller-side' = everything we recommend for controller-side is supported, c) docstring with specific versions otherwise
20:08:09 <abadger1999> +1
20:08:13 <jillr> that makes sense
20:08:34 <tadeboro> +1 (and +1 for example briantist wants - I want it too ;))
20:08:37 * lmodemal Sorry...need to log off. Have a great day all :)
20:08:40 <briantist> +1 (but please update developer documentation with an example of what this looks like)
20:08:47 <felixfontein> Proposal: a) no docstring = everything we recommend for remote-side is supported, b) docstring 'Python versions supported: as for controller-side' = everything we recommend for controller-side is supported, c) docstring with specific versions otherwise: 'Python versions supported: <explicit list>'
20:08:53 <felixfontein> lmodemal: thanks for being around!
20:09:02 <jillr> +1 (with docs)
20:09:20 <felixfontein> are the above examples a good start?
20:09:43 <tadeboro> OK from my side.
20:09:46 <felixfontein> (they should be expanded, this is a one-line fits all version ;) )
20:09:50 <jillr> yes
20:09:52 <briantist> sure
20:10:18 <abadger1999> wfm
20:10:31 <cybette> cybette-clock says: we're 16 min in topic "Python version requirements for module_utils", and 1:10 into the meeting
20:10:34 <felixfontein> VOTE: convention for module_utils: a) no docstring = everything we recommend for remote-side is supported, b) docstring 'Python versions supported: as for controller-side' = everything we recommend for controller-side is supported, c) docstring with specific versions otherwise: 'Python versions supported: <explicit list>'
20:11:04 <jillr> +1
20:11:06 <tadeboro> +1
20:11:08 <briantist> +1
20:11:22 <felixfontein> +1
20:11:24 <andersson007_> +1
20:12:17 <felixfontein> #chair
20:12:18 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cybette dericcrago felixfontein gundalow jillr lmodemal samccann tadeboro
20:12:31 <abadger1999> +1
20:12:38 <dericcrago> +1
20:13:27 <felixfontein> #agreed convention for module_utils: a) no docstring = everything we recommend for remote-side is supported, b) docstring 'Python versions supported: as for controller-side' = everything we recommend for controller-side is supported, c) docstring with specific versions otherwise: 'Python versions supported: <explicit list>'
20:13:32 <felixfontein> great :)
20:13:44 <felixfontein> should we specify how a version bump should be announced?
20:13:53 <misc> so when there is a new minor version of python, the explicit list must be updated each time, despites python being usually good at not breaking stuff (usually) ?
20:14:01 <felixfontein> or do we hope for common sense?
20:14:20 <felixfontein> misc: I would expect the explicit list to say something like `2.7, 3.6+`
20:14:24 <misc> felixfontein: hoping for common sense, I would say "bold move"
20:14:33 <felixfontein> misc: yes :)
20:15:25 <tadeboro> misc: I would hope most devs will use one of the symbolc options before resorting to version numbers. If not, I would say devs need to update the llist if the version range is bounded from above.
20:15:38 <briantist> re: announcement, seems like a good thing for changelog entry, but this is bringing up questions about where it fits. Seems like it's a breaking change (really only for things outside the collection using the module_dep, which in many cases is none), but that limits the ability to change it to major versions
20:15:50 <felixfontein> Proposal: collections have to announce dropping support for Python versions in their changelog, if possible in advance (i.e. announce in previous versions when support will be dropped); if collections are aware of users, they should announce it directly to their known users, and/or to https://github.com/ansible-collections/overview/issues/45
20:16:26 <felixfontein> briantist: module_utils is part of the public interface, so bumping the version requirement is a breaking change anyway
20:16:44 <briantist> wondering (and this is probably a separate issue, for a separate meeting),  but is it possible to specify publicly that a module_util is for internal use only?
20:16:46 <jillr> briantist: changes to python support versions should already be a major/breaking change anyway
20:16:50 <felixfontein> (usually you don't just bump the requirement for module_utils, but for more parts of the collections, like your modules using module_utils :) )
20:16:56 <briantist> by convention of course,  not technically enforced, but could change the landscape on making changes to it
20:17:13 <acozine> briantist: internal to a collection, you mean?
20:17:14 <briantist> jillr: yeah true
20:17:25 <briantist> acozine: yes
20:17:29 <felixfontein> briantist:  I think it is ok, if it is documented appropriately from the beginning of the module_util's existence (or if it uses a leading underscore in the filename)
20:17:56 <felixfontein> making it internal later would be a breaking change, since it changes the public API
20:17:59 <briantist> ^ makes sense
20:18:04 <jillr> agreed on internal module_utils, with proper documentation
20:18:09 <abadger1999> +1 to leading underscore
20:19:12 <felixfontein> Proposal: module_utils can be marked for only internal use in the collection, but they MUST document this and SHOULD use a leading underscore for filenames. Making an existing module_utils private is a breaking change and requires a major version bump.
20:19:27 <briantist> +1
20:19:42 <jillr> +1
20:19:43 <abadger1999> I would require leading underscore
20:19:50 <abadger1999> But if I'm outvoted, that's okay
20:20:05 <felixfontein> should we update this to require leading underscore? I'm fine with that
20:20:16 <felixfontein> (the leading underscore could also be in a directory name)
20:20:17 <andersson007_> +1 for require
20:20:22 <tadeboro> I would require it as abadger1999 suggested.
20:20:38 <jillr> +1
20:20:42 <felixfontein> Proposal: module_utils can be marked for only internal use in the collection, but they SHOULD document this and MUST use a leading underscore for filenames. Making an existing module_utils private is a breaking change and requires a major version bump.
20:21:00 <felixfontein> (or should it be two MUSTs? I think a leading underscore is standard enough in the Python world to not need documentation)
20:21:03 <abadger1999> +1
20:21:10 <briantist> I'm fine with leading underscore either required or not
20:21:26 <andersson007_> + 1 for MUST MUST:)
20:21:48 <felixfontein> does anyone else wants two MUSTs?
20:21:58 <tadeboro> +1 (MUST for _, I do not care much about SHOUD/MUST documentation).
20:22:36 <acozine> what is the advantage of internal-only module_utils?
20:22:37 <felixfontein> I think I refer SHOULD for documentation, or not even mentioning documentation, but requiring the underscore
20:22:42 <jillr> +1 MUST document, do not have a preference about MUST/SHOULD have _
20:22:47 <acozine> why not share?
20:23:17 <felixfontein> acozine: sometimes you have code that is not very clean, has very peculiar requirements, or has some other versions that you don't want anyone else to use it :)
20:23:21 <jillr> I would rather be explicit and document than assume folks know the convention
20:23:26 <briantist> acozine: imo if the util is more about deduplication of code within a collection, and has a low probability of being used outside of it, being able to refactor it together in the collection (nothing in collection breaks) is useful, without having to wait for major version
20:23:28 <abadger1999> acozine: With an internal module_utils, plugins/modules within the collection can share.  But other collections would be warned not to use them
20:23:29 <felixfontein> if you make it public, you have to promise to keep its interface supported
20:23:41 <tadeboro> acozine: having external users for something that is an internal API is bad for both parties involved ;)
20:23:57 <acozine> all right, sounds like there's a solid use case
20:24:02 <felixfontein> Proposal: module_utils can be marked for only internal use in the collection, but they MUST document this and MUST use a leading underscore for filenames. Making an existing module_utils private is a breaking change and requires a major version bump.
20:24:16 <briantist> +1
20:24:18 <acozine> +1
20:24:18 <jillr> +1
20:24:19 <andersson007_> +1
20:24:29 <felixfontein> +1
20:24:35 <tadeboro> +1 (since MUST/MUST seems to be the intersection of what we want ;))
20:24:42 <felixfontein> tadeboro: yep :)
20:24:49 <abadger1999> +1
20:25:16 <felixfontein> #chair
20:25:16 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cybette dericcrago felixfontein gundalow jillr lmodemal samccann tadeboro
20:25:22 <dericcrago> +1
20:25:48 <gundalow> +1
20:26:20 <felixfontein> #agreed module_utils can be marked for only internal use in the collection, but they MUST document this and MUST use a leading underscore for filenames. Making an existing module_utils private is a breaking change and requires a major version bump.
20:26:40 <felixfontein> ok
20:27:02 <felixfontein> do we want to be more explicit on announcing a Python version bump for module_utils (and also plugin_utils for controller-side only stuff)?
20:27:33 <jillr> beyond the changelog you mean?
20:27:44 <felixfontein> Proposal: collections have to announce dropping support for Python versions in their changelog, if possible in advance (i.e. announce in previous versions when support will be dropped); if collections are aware of collection users (which import their code), they should announce it directly to their known users, and/or to https://github.com/ansible-collections/overview/issues/45
20:27:52 <felixfontein> something like this
20:28:28 <jillr> should we also recommend the bullhorn?
20:28:49 <felixfontein> Proposal: collections have to announce dropping support for Python versions in their changelog, if possible in advance (i.e. announce in previous versions when support will be dropped); if collections are aware of collection users (which import their code), they should announce it directly to their known users, and/or to https://github.com/ansible-collections/overview/issues/45, and/or The
20:28:54 <tadeboro> I would say changelog is a must, all other is optional but highly recommended.
20:28:55 <felixfontein> Bullhorn
20:29:58 <jillr> yep, changelog is must, the others are should but strongly recommended. lgtm
20:30:09 <abadger1999> wfm.
20:30:33 <felixfontein> Proposal: collections MUST announce dropping support for Python versions in their changelog, if possible in advance (i.e. announce in previous versions when support will be dropped); if collections are aware of collection users (which import their code), they SHOULD announce it directly to their known users, and/or to https://github.com/ansible-collections/overview/issues/45, and/or The
20:30:39 <felixfontein> Bullhorn
20:30:43 <cybette> cybette-clock says: we're 36 min in topic "Python version requirements for module_utils", and 1:30 into the meeting
20:31:27 <briantist> wfm as well
20:32:39 <abadger1999> +1
20:32:49 <tadeboro> I say we vote on the last proposal since it looks great.
20:33:01 <felixfontein> VOTE: collections MUST announce dropping support for Python versions in their changelog, if possible in advance (i.e. announce in previous versions when support will be dropped); if collections are aware of collection users (which import their code), they SHOULD announce it directly to their known users, and/or to https://github.com/ansible-collections/overview/issues/45, and/or The
20:33:07 <felixfontein> Bullhorn
20:33:08 <andersson007_> +1
20:33:11 <jillr> +1
20:33:11 <briantist> +1
20:33:20 <dericcrago> +1
20:33:22 <tadeboro> +1
20:33:27 <cybette> +1
20:33:31 <acozine> +1
20:34:26 <felixfontein> #agreed collections MUST announce dropping support for Python versions in their changelog, if possible in advance (i.e. announce in previous versions when support will be dropped); if collections are aware of collection users (which import their code), they SHOULD announce it directly to their known users, and/or to https://github.com/ansible-collections/overview/issues/45, and/or The
20:34:32 <felixfontein> Bullhorn
20:34:33 <felixfontein> ok :)
20:34:42 <felixfontein> I think we now covered all aspects of this topic
20:34:53 <felixfontein> does someone disagree?
20:34:54 <abadger1999> Yay!
20:35:07 <acozine> Pythonapalooza is over?
20:35:09 <felixfontein> and does someone have a suggestion for another topic, or should we jump to open floor and finish "early"? :)
20:35:14 <jillr> \o/
20:35:33 <acozine> go for open floor
20:35:35 <cybette> +1 for "early" :D
20:35:39 <acozine> it will be a record
20:35:43 <felixfontein> acozine: I think it *finally* is! well, ompragash needs to adjust the PR and we can vote on the final PR hopefully next week, but I think all open questions are resolved!
20:35:49 <felixfontein> #topic Open floor
20:36:09 <felixfontein> haha, actually we had a very small community meeting once when a lot of people were away, and we finished in something like 30 minutes ;)
20:36:25 <felixfontein> let's see if we ever manage to break that record ;)
20:37:06 <felixfontein> if nobody has something for open floor, I'll close in a few minutes
20:38:29 <gundalow> Nothing else from me
20:38:49 * acozine hums the Jeopardy theme song
20:39:02 <cybette> acozine: I had the same tune in my head!
20:39:25 <felixfontein> :)
20:39:28 <felixfontein> #endmeeting