18:02:31 <felixfontein> #startmeeting Ansible Community Meeting
18:02:31 <zodbot> Meeting started Wed Oct 28 18:02:31 2020 UTC.
18:02:31 <zodbot> This meeting is logged and archived in a public location.
18:02:31 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:02:31 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:03:03 <felixfontein> abadger1999: andersson007_: gundalow: cyberpear: gwmngilfen: cybette: samccann: acozine: lmodemal:
18:03:18 <andersson007_> hi
18:03:47 <lmodemal> Hello :)
18:03:47 <abadger1999> Hello!
18:04:47 <acozine> hi
18:05:06 <acozine> I'm digging around for some paperwork, but will be fully here in five
18:05:36 <felixfontein> #chair andersson007_ abadger1999 lmodemal acozine
18:05:36 <zodbot> Current chairs: abadger1999 acozine andersson007_ felixfontein lmodemal
18:05:52 <felixfontein> I just had to fetch my dinner, so if I make strange pauses, it's because I'm eating ;)
18:06:16 <felixfontein> #topic agenda https://github.com/ansible/community/issues/539
18:07:12 <felixfontein> #topic updates
18:07:44 <felixfontein> #info andersson007_ and felixfontein started creating new collections from material from c.g/c.n: community.postgresql, community.routeros, community.docker
18:08:07 <abadger1999> Cool! That's awesome
18:08:12 <felixfontein> especially losing the postgresql and docker modules will speed up c.g's CI
18:08:27 <acozine> that is great - having more granular collections makes things much easier to find
18:08:33 <andersson007_> i'd like to release 0.1.0 of c.p. tomorrow
18:08:43 <felixfontein> cool!
18:09:00 <felixfontein> c.routeros 0.1.0 is already released, c.docker might follow today or tomorrow
18:09:33 <cybette> oh meeting is early today
18:09:46 <felixfontein> cybette: yep, welcome to winter time :)
18:09:50 <felixfontein> #chair cybette
18:09:50 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette felixfontein lmodemal
18:09:57 <acozine> timechange in Scandinavia, I guess
18:10:03 <felixfontein> all over europe
18:10:15 <cybette> haha yeah we've fallen back over the weekend
18:10:28 <felixfontein> let's see for how more often
18:10:41 <felixfontein> but then, they already wanted to stop last year (which was totally unrealistic) :)
18:14:25 <felixfontein> potential topics for today: 1) criteria for new collections for 2.11; 2) removing `authors` from botmeta; 3) should sphinx extension become part of antsibull; 4) accept new plugins/modules from companies in c.g/c.n?; 5) https://github.com/ansible-collections/community.general/pull/1083; 6) merge https://github.com/ansible-collections/community.general/pull/1191 or not
18:14:25 <github-linkbot> https://github.com/ansible-collections/community.general/pull/1083; | open, created 2020-10-13T09:07:38Z by aminvakil: archive: remove path folder itself when remove paramater is true [affects_2.10,bug,community_review,files,integration,module,plugins,tests]
18:14:53 <felixfontein> for 1) and 2) it's probably wait until gundalow is around. should we go through the others until then?
18:15:00 <abadger1999> SOunds good
18:15:14 <acozine> +1
18:15:17 <felixfontein> ok :)
18:15:51 <felixfontein> #topic should https://github.com/felixfontein/ansible-basic-sphinx-ext become a part of antsibull, or if not gh.com/ansible-community?
18:16:23 <abadger1999> I think it makes sense.
18:16:25 <felixfontein> I think all voices I heard so far thought that it kind of belongs to antsibull-docs, and abadger1999 also voiced that today
18:16:29 <felixfontein> :)
18:16:36 <acozine> putting the sphinx extension into antsibull seems like a natural fit
18:16:41 <felixfontein> does anyone thing it is not a good idea?
18:16:58 <abadger1999> We kind of want third parties to be able to use antisbull-docs to build their own collection docs so I think they belong together.
18:17:01 * acozine tries to think like a devil's advocate
18:17:17 <felixfontein> abadger1999: something related I thought about earlier: what do you think of separating antsibull-doc from the remaining parts of antsibull?
18:17:28 <abadger1999> yeah, I've wondered that too.
18:17:52 <acozine> could people use the sphinx theme without using the other parts of antsibull-doc?
18:17:58 <felixfontein> (reason behind is that the extension requires sphinx, and that's a rather big piece that's totally not needed by the rest of antsibull)
18:18:09 <abadger1999> I think deps would be the biggest benefit but I'm not sure if there are a lot of deps which are not held in common.
18:18:20 <abadger1999> <nod>
18:18:25 <abadger1999> Yeah, exactly that sort of thing.
18:19:13 <abadger1999> Most people are likely to have sphinx easily availabe , if not installed, though.  So I'm not sure if it's an immediate problem.
18:19:50 <felixfontein> the extension depends on pygments and sphinx, which is not required by antsibull
18:19:55 <abadger1999> Would you include ansible-changelog with -docs?  I think those are both end-usery so it makes sense.
18:20:17 <felixfontein> good question. it's kind of unrelated, and a dependency of antsibull-build
18:20:40 <felixfontein> you can use antsibull-changelog without ever needing antsibull-docs or antsibull-build
18:20:53 <acozine> when you say "separating antsibull-doc from the rest of antsibull", do you mean making it a separate repo? separate PyPI package? both? something else?
18:21:19 <felixfontein> I guess every collection maintainer who doesn't want to create their own docsite won't need antsibull, but they need antsibull-changelog
18:21:24 <abadger1999> Separate pypi package is where I see the main benefit.  A separate repo might follow naturally from doing that.
18:21:32 <felixfontein> acozine: separate pypi package
18:21:35 <felixfontein> yep
18:22:08 <acozine> thanks for clarifying
18:22:42 <felixfontein> are there people using antsibull-build who don't use antsibull-docs?
18:23:02 <felixfontein> like when someone wants to rebuild the ansible package, but not the docsite?
18:23:34 <abadger1999> I don't think so.  I think the other way around is the big thing (using antsibull-docs without antsibull-build)
18:24:04 <abadger1999> I mean... on a given day I might only use antsibull-build without antsibull-docs but I would be involved in doing both.
18:24:18 <abadger1999> If you think about the course of a week.
18:24:31 <felixfontein> true :)
18:26:13 <abadger1999> Should we approve merging and maybe do some preliminary work on splitting to decide whether there's benefit there over the course of this week?
18:26:28 <felixfontein> sounds good to me
18:26:41 <felixfontein> it might make sense to merge some of the open PRs before starting splitting things :)
18:27:08 <abadger1999> heh :-) Yeah, true.  Gotta catch up from my vacation :-)
18:27:19 <felixfontein> should we vote on this, or is it fine if nobody disagrees?
18:27:55 <abadger1999> Proposal: merge ansible-basic-sphinx-ext into antsibull
18:27:56 <abadger1999> +1
18:28:07 <abadger1999> voting doesn't hurt so might as well.
18:28:12 <felixfontein> true
18:28:13 <felixfontein> +1
18:28:25 <acozine> +1
18:28:35 <felixfontein> #chair
18:28:35 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette felixfontein lmodemal
18:28:43 <lmodemal> +1
18:28:56 <cybette> +1
18:29:01 <andersson007_> abstained
18:30:05 <legreffier> +1
18:30:30 <felixfontein> #chair legreffier
18:30:31 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette felixfontein legreffier lmodemal
18:30:55 <abadger1999> #info Will merge ansible-basic-sphinx-ext into antsibull (+1:6, 0:1, -1:0)
18:31:12 <felixfontein> sounds good!
18:31:31 <felixfontein> we should probably rename the extension, also because webknjaz pointed out that its name is very un-shpinx-extension-y
18:31:43 <abadger1999> Heh :-)
18:31:45 <abadger1999> yeah
18:32:04 <acozine> so . . . `this_aint_your_average_sphinx_extension`?
18:32:47 <felixfontein> maybe sphinx_antsibull_extension or something like that
18:33:02 <felixfontein> or sphinx_antsibull_docs
18:34:18 <webknjaz> "docs" suffix sounds redundant because it's already going to be in `conf.py` which is unambiguously sphinx-bound
18:34:19 <acozine> I think they typically use hyphens
18:34:20 <legreffier> https://github.com/ansible/ansible/compare/devel...ylmrx:devel < here's a change i would like to submit an PR for. is it interesting enough of a feature ? my recursion is probably dirty, should I make the inner function (_graph_group_dot_recurse) outside of its parent, or is it ok ?
18:34:29 <abadger1999> yeah.  We can talk about it in the merge PR.
18:34:37 <acozine> at least, we've used https://github.com/readthedocs/sphinx-notfound-page
18:34:49 <felixfontein> webknjaz: true.
18:35:06 <legreffier> is it a ok to submit a PR with "doubtful" code on your side ?
18:35:17 <felixfontein> acozine: the 'outer' name does, but the inner name is something that's python importable I think, I guess the standard way is to convert dashes to underscores
18:35:25 <acozine> maybe `sphinx-antsibull` ?
18:35:29 <acozine> felixfontein: ah, gotcha
18:35:53 <felixfontein> acozine: sounds good
18:36:13 <legreffier> please advise <3
18:36:23 <webknjaz> @acozine: there's a difference between the PyPI name and Python importable. You can use dashes on PyPI (they are normalized to underscores tho) but in `conf.py` it must be a valid Python identifier (basically a dir name in the repo) — hence no dashes or dots (unless it's nested)
18:36:33 <felixfontein> legreffier: I'm not sure if this is the best place (and time) to ask :)
18:37:00 <felixfontein> legreffier: creating a PR doesn't hurt, in the worst case the core team will decide that they don't want that feature and close it
18:38:22 <felixfontein> ok. let's continue with the next topic.
18:38:25 <acozine> legreffier: for feedback on the code itself, you can try the ansible-devel channel
18:38:40 <felixfontein> hmm, 4) is also something we should discuss when gundalow is around
18:39:11 <felixfontein> amin isn't around for 5)
18:39:11 <abadger1999> legreffier: You can submit a PR for that.  The ansible-base team is probably who would look at it (they have meetings in #ansible-community on Tues and Thurs).  I would make the recurse function outside of the parent (it's easier to read, understand, and test when it's not nested)
18:39:13 <felixfontein> so:
18:39:36 <felixfontein> #topic should we merge https://github.com/ansible-collections/community.general/pull/1191 or not - i.e. is removing collection dependencies a breaking change that has to wait for a major release, or not?
18:39:37 <github-linkbot> https://github.com/ansible-collections/community.general/pull/1191 | open, created 2020-10-28T11:57:21Z by patchback[bot]: [PR #1157/20f470cc backport][stable-1] Remove ansible.posix dependency [affects_2.10,bug,has_issue,module,module_utils,needs_revision,needs_triage,new_contributor,plugins,system,tests,unit]
18:39:56 <geerlingguy> Late again, oops!
18:39:58 * cyberpear arrives late, needs to add calendar reminder
18:40:02 <felixfontein> legreffier: abadger1999: the core team meetings are in #ansible-meeting :)
18:40:06 <felixfontein> #chair geerlingguy
18:40:06 <zodbot> Current chairs: abadger1999 acozine andersson007_ cybette felixfontein geerlingguy legreffier lmodemal
18:40:10 <felixfontein> #chair cyberpear
18:40:10 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear cybette felixfontein geerlingguy legreffier lmodemal
18:40:30 <abadger1999> Doh!  yeah, my fingers typed a different thing than my brain was saying
18:40:43 <abadger1999> legreffier: https://github.com/ansible/community/tree/master/meetings   "Core Team Meeting" on that page
18:41:23 <felixfontein> about the new topic: that PR removes the ansible.posix dependency from community.general. it vendors the little piece of code that was used from it by exactly one module.
18:41:49 <felixfontein> the question is whether collection dependencies are part of the API, i.e. whether removing them is a breaking change to the collection's API
18:42:28 <felixfontein> the changelog fragment is major_change, so it will be easy to see it in the changelog, and it's only relevant for people who install community.general manually and do not use ansible 2.10
18:42:29 <abadger1999> To me, it feels like it does as it breaks playbooks.
18:42:58 <abadger1999> does == does make a breaking change
18:43:19 <felixfontein> it breaks playbooks which assume that installing community.general also installs ansible.posix
18:43:23 <abadger1999> yeah
18:43:23 <acozine> would the playbook break? or just use `mount` from the community.general collection?
18:43:41 <felixfontein> acozine: if the playbook does not use anything from ansible.posix, it won't break
18:43:51 <felixfontein> and if the playbook already installed ansible.posix manually, it won't break either
18:44:37 <legreffier> (ok didn't realize this was an on-going meeting, sorry for the noise. and thanks a lots for the advise, I'll work on some UTs for these and fixing a bit of logic. take care.)
18:44:42 <felixfontein> the collection dependencies are not really part of the publicly documented API of the collection (you cannot see them on https://galaxy.ansible.com/community/general)
18:44:43 <acozine> ah, I see - a playbook that used ansible.posix for something else, and depended on the community.general collection to install it, would break
18:44:50 <felixfontein> legreffier: no problem!
18:45:22 <felixfontein> acozine: yes. but then also bugfixes breaks playbooks which assume that a bug is around.
18:46:07 <cyberpear> I'd say it's not a breaking change as it's only a dep, and if they need the other, they should specify it explicitly.
18:47:33 <felixfontein> geerlingguy: andersson007_: what do you think? you both work with collections a lot
18:48:16 <andersson007_> it can wait for a major release
18:49:02 <abadger1999> if we take the "deps should be specified explicitly" stance, we probably should document that somewhere on docs.a.c... "When you use something from a collection, make sure you explicitly install them.  Do not rely on dependencies from another collection to bring them in for you"
18:49:37 <abadger1999> (following up from cyberpear's counter-proposal)
18:50:46 <cyberpear> if we want "zero friction" outside of a major release, no real harm in leaving the deps, though...
18:51:01 <geerlingguy> I feel like as with roles, I don't rely on collection dependencies to get me the collections I need
18:51:31 <geerlingguy> E.g. if I use ansible.posix, I don't rely on the fact that some other collection that my playbook uses might depend on it, I explicitly add it to my requirements.yml file
18:51:48 <geerlingguy> But I've learned that behavior over the years from getting burned by soft dependencies, changing dependencies, etc.
18:51:52 <felixfontein> cyberpear: except that users have to wait until next year before they can get a slimmer version of c.g :) but that's the case for all other dependencies anyway
18:52:24 <cyberpear> right... I wish pip/PyPI had a way to specify weak dependencies
18:52:28 <geerlingguy> We're still very early in the collections world, so I think we'd be safe in setting that precedent now if we want—that is, it's better to not rely on collection dependencies if you're using collections.
18:53:13 <geerlingguy> There could be some users annoyed by it, but I think the number will be fairly low, at least for the next few months, as I still have yet to see many people in the wild using collections besides what is baked into 2.10 with 'pip install ansible'
18:53:33 <cyberpear> I don't think any distros even ship 2.10 at all yet
18:53:38 <gundalow> Hi, I'm here now
18:53:43 <cyberpear> so it's only pip users who'd even be hit by it is my guess
18:53:51 <felixfontein> cyberpear: arch linux does :) but it's a rolling release distro
18:54:06 <cyberpear> IIUC, even RH doesn't ship 2.10 to customers?
18:54:10 <cyberpear> felixfontein: fair enough
18:54:23 <abadger1999> <nod> I agree with geerlingguy that we can set expectations now.
18:54:42 <webknjaz> @cyberpear: there's extras for that
18:54:58 <acozine> we can certainly document "don't rely on collection dependencies to install things you need"
18:55:28 <gundalow> If people need `ansible.posix` though didn't notice they aren't installing is because they are using `community.general` (which ships a.posix) then I think it's OK for them to realise that. AFAIK the error message from ansible-playbook is fairly sensible
18:55:29 <felixfontein> should we vote? or do we need more discussion?
18:56:48 <felixfontein> VOTE: should we remove the dependency on ansible.posix for the next minor community.general release, and teach users that they shouldn't rely on indirect dependencies?
18:56:56 <gundalow> +1
18:57:11 <cyberpear> +1
18:57:29 <andersson007_> "teach users":) , ok +1
18:57:34 <acozine> +1
18:57:43 <felixfontein> I'm +-0
18:57:54 <abadger1999> +0  ;; As long as it's documented I'll go along with the consensus.
18:58:23 <lmodemal> I don't know enough about this to vote
18:58:45 <felixfontein> #chair
18:58:45 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear cybette felixfontein geerlingguy legreffier lmodemal
18:59:04 <abadger1999> lmodemal: That's fine :-)
18:59:16 <geerlingguy> +1
18:59:58 <abadger1999> One day you will and you'll be like, "Man I wish I knew enough to vote the other way back then" ;-)
19:00:03 <geerlingguy> I'm mostly +1 for trying to minimize both the size of c.g itself and the huge amount of dependent stuff it ties into currently. It still has too many important and oft-used modules in it to be as big as it is currently.
19:00:21 <felixfontein> #agreed remove the dependency on ansible.posix for the next minor community.general release, and teach users that they shouldn't rely on indirect dependencies (5 x +1, 2 x 0, 0 x -1)
19:00:27 <acozine> #info acozine to update https://docs.ansible.com/ansible/latest/user_guide/collections_using.html, possibly other pages with "don't rely on indirect dependencies"
19:00:29 <felixfontein> geerlingguy: that's also my goal ;)
19:00:29 <lmodemal> lol abadger1999 You're prob right
19:00:47 <felixfontein> great
19:01:03 <felixfontein> #topic should we reschedule the meeting to another time (or even day)?
19:01:24 <felixfontein> quick poll: is this time still good for everyone? (now that we have winter time, or are close to it, depending on your timezone)
19:01:42 <felixfontein> if not, please indicate whether you prefer earlier, later, ...
19:01:45 <geerlingguy> good for me, I just have a crazy schedule every day :P
19:02:06 <lmodemal> This time works fine for me :)
19:02:13 <felixfontein> #chair
19:02:14 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear cybette felixfontein geerlingguy legreffier lmodemal
19:02:23 <acozine> current time good for me
19:02:29 <andersson007_> works for me as well
19:02:32 <felixfontein> it might be more a problem for people outside the US :)
19:02:40 <abadger1999> This is fine but I can shift both earlier and later.
19:02:40 <cyberpear> no complaints here
19:03:02 <felixfontein> gundalow: how about you?
19:03:09 <felixfontein> cybette?
19:03:20 <cybette> it's a bit late for me but doable
19:03:28 <abadger1999> (and I'm happy to shift if it makes it better for the Europeans)
19:04:13 <cybette> I'm a night owl anyway. I do better in a meeting at midnight than 8am
19:04:14 <felixfontein> for me one hour earlier or later would be better, at least during winter time. but if I'm the only one, it should be fine if we stick to the current time
19:04:16 <gundalow> this is right over dinner/family time for me now the clocks have changed (6-7pm)
19:04:39 <cybette> i think it shifts again next week for US
19:04:40 <felixfontein> gundalow: would one (or more) hour later be better? or one (or more) hour earlier?
19:04:59 <gundalow> later would be better since it generally runs long
19:05:09 <felixfontein> heh, true. like today :D
19:05:34 <gundalow> Actually, can we wait two weeks till the new starts have joined
19:05:43 <gundalow> I haven't checked that this works for them
19:05:44 <felixfontein> sounds good to me
19:05:56 <felixfontein> moving it one hour to the back would be good for me too, but let's see what the new ones say
19:06:19 <gundalow> #agreed revisit moving meeting once two new starts have joined
19:06:28 <gundalow> what's next on the agenda?
19:06:47 <gundalow> felixfontein: what was `hmm, 4) is also something we should discuss when gundalow is around`
19:07:18 <felixfontein> we have left: 1) criteria for new collections for 2.11; 2) removing `authors` from botmeta; 3) 4) accept new plugins/modules from companies in c.g/c.n?; 4) https://github.com/ansible-collections/community.general/pull/1083
19:07:18 <github-linkbot> https://github.com/ansible-collections/community.general/pull/1083 | open, created 2020-10-13T09:07:38Z by aminvakil: archive: remove path folder itself when remove paramater is true [affects_2.10,bug,community_review,files,integration,module,plugins,tests]
19:07:40 <felixfontein> for the first three I think it's better if you're around as well
19:08:18 <felixfontein> 2) and 3) are probably quicker to discuss, so let's delay 1) for next week (or so)
19:08:19 <andersson007_> i'd suggest moving 1) at least to the next meeting
19:08:26 <felixfontein> andersson007_: +1 :)
19:08:33 <andersson007_> felixfontein: was 1 sec faster:)
19:09:00 <andersson007_> 2) is short enough for now
19:09:35 <aminvakil> 4) can be delayed until next meeting too, it's not important.
19:09:37 <felixfontein> #topic should we remove `authors` from botmeta? https://github.com/ansible/community/issues/539#issuecomment-706947663
19:10:25 <gundalow> For the large stuff maybe we can create proposals in https://github.com/ansible-collections/overview/discussions?discussions_q=category%3AProposals
19:10:30 <cyberpear> I think it's at least somewhat valuable to maintain the difference, "who originally wrote this" vs "who maintains this"
19:10:53 <felixfontein> cyberpear: the information is already availabe in the module itself, and currently it's enforced that it is machine-readable
19:11:00 <andersson007_> i'd remove them to make BOTMETA.yml clearer. why we shouldn't?:)
19:11:17 <andersson007_> felixfontein: +1
19:11:21 <felixfontein> I guess the question is whether we want to change the strict format requirements in the module docs
19:11:41 <felixfontein> if we remove that, we should keep them in BOTMETA. if we keep the restrictions on `authors:` in modules/plugins, we don't need them in BOTMETA
19:11:44 <gundalow> today BOTMETA.yml is 1) Only exists in collection repos with the Bot 2) Only used by the bot to ping maintainers and accept their `shipits`
19:12:06 <gundalow> today the bot knows how to read `authors` in a module
19:12:24 <andersson007_> so authors in botmeta are extra
19:12:26 <cyberpear> in that case, +1 from me, since it's in each module, no need to dupe in BOTMETA
19:12:27 <felixfontein> gundalow: also for plugins, I hope?
19:12:35 <gundalow> I don't think the bot knows how to read `authors` from non-module plugins (that might not even be a thing in the plugin spec)
19:12:48 <acozine> +1 for deduplicating
19:12:50 <gundalow> today botmeta can define maintainers are directory level
19:12:50 <felixfontein> gundalow: it will be, once validate-modules also validates plugins :)
19:12:59 <gundalow> felixfontein: I'm looking forward to that
19:13:03 <felixfontein> gundalow: me too!
19:13:19 <andersson007_> acozine: `deduplication` is a good word for this case:)
19:14:11 <felixfontein> VOTE: remove author: from BOTMETA?
19:14:13 <felixfontein> +1
19:14:18 <abadger1999> +1
19:14:21 <andersson007_> +1
19:15:26 <cyberpear> +1
19:15:51 <acozine> +1
19:15:58 <cybette> +1
19:16:13 * acozine has to skip out
19:16:27 <felixfontein> acozine: bye, and thanks for being here!
19:16:45 <felixfontein> #agreed remove author information from BOTMETA (i.e. deduplicate)
19:16:52 <andersson007_> cool, i'll tidy up c.g's botmeta ASAP
19:17:06 <felixfontein> #action andersson007 remove `author:` from BOTMETA
19:17:11 <felixfontein> there you go ;)
19:17:16 <felixfontein> thanks andersson007_!
19:17:24 <andersson007_> np:)
19:17:41 <felixfontein> do you want to touch another topic (accept new plugins/modules from companies in c.g/c.n?)?
19:17:57 * lmodemal waves
19:18:15 <felixfontein> background is that we have a PR for an inventory plugin for Yandex cloud from a Yandex employee
19:18:54 <felixfontein> he says there are no plans to add more things in the near future, but I'm not sure whether we should accept something that easily can blow up into a large set of modules
19:19:03 <cyberpear> def accept imo
19:19:23 <felixfontein> so far when we had PRs from companies who wanted to add a set of modules, we told them to create their own collection
19:19:43 <geerlingguy> ^ this is the way
19:20:07 <felixfontein> this case is a bit special, since there's only one plugin right now, and not a group of them
19:20:25 <abadger1999> I think we should be consistent.  But a range could still be consistent.
19:20:59 <abadger1999> Do we have some rules for individual contributors?
19:21:04 <felixfontein> true. if it would be for a product that obviously only needs 1-2 modules/plugins (or another small integer), it would definitely be ok for me
19:21:20 <felixfontein> but a plugin for some cloud service can quickly result in a LOT of modules for that cloud service
19:21:26 <abadger1999> Yeah
19:21:28 <andersson007_> speaking about Yandex, they have several products that can be theoretically supported by ansible, e.g. cloud, clickhouse, etc. make sense to create a separate namespace
19:21:28 <felixfontein> abadger1999: I don't think we have
19:22:41 * cyberpear has item for open floor
19:22:45 <felixfontein> andersson007_: I tihnk so too, but I also understand that going through the hassle of setting up a namespace + collection for just one plugin is quite some work
19:22:48 <abadger1999> I'd be okay for 1-2 as well.
19:23:05 * cybette has couple of items for open floor
19:23:07 <felixfontein> abadger1999: 1-2 at the moment, or 1-2 max?
19:23:27 <felixfontein> hmm maybe let's discuss this next week, and everyone can think about it, and let's skip to open floor
19:23:33 <andersson007_> felixfontein: true. and it's only "theoretically"
19:23:34 <cyberpear> I'd say 1-2 of each pluin type?
19:23:36 <abadger1999> I guess... another question would be.... can we safely use c.g as an incubator?
19:24:09 <gundalow> If there were 2+ then I'd say must be own collection
19:24:14 <andersson007_> i suggest creating community.incubator collection
19:24:18 <abadger1999> (yandex has 2 plugins for one year,  next year they want to add 8 more.  At that point, they create their own collection and move the ones from c.g into the new collection)
19:24:47 <abadger1999> felixfontein: +1 to table until next week.
19:24:50 <felixfontein> abadger1999: and suddenly we're back at "we have to move things from c.g somewhere else". fortunately it's nothing that's redirected from ansible-base, it will just annoy their users :)
19:24:59 <abadger1999> Yeah
19:25:11 <felixfontein> #topic open floor
19:25:23 <cybette> Reminder about Ansible Hacktoberfest 2020 in 2 days (Oct 30)
19:25:28 <cybette> #info Ansible Hacktoberfest 2020 https://etherpad.opendev.org/p/ansible-hacktoberfest-2020
19:26:00 <cybette> #info Ansible Contributor Summit Day 1 playlist https://www.youtube.com/playlist?list=PL0FmYCf7ocrYoVe5nO52II9fbO4Y_hq8_
19:26:17 <felixfontein> cyberpear: how many people already signed up for the hacktoberfest?
19:26:36 <felixfontein> argh
19:26:40 <felixfontein> me and tab...
19:26:40 <cyberpear> tab complete strikes again! :P
19:26:51 <cybette> :D
19:26:52 <felixfontein> sorry :)
19:27:10 <gundalow> 11 people so far
19:27:11 <felixfontein> let's make a rule that nicks have to differ after at least two letters :P
19:27:14 <cybette> felixfontein: 12 registered so far
19:27:18 <felixfontein> s/at least/at most/
19:27:27 <cybette> gundalow: one more just registered :)
19:27:46 <cyberpear> thanks for getting the playlists up!
19:27:49 <felixfontein> ok! I might be around, but I'm not sure how much time I'll have on Friday
19:27:54 <gundalow> nice
19:28:12 <felixfontein> cybette: do you have more points, or should we continue with cyberpear's topics?
19:28:13 <gundalow> only two names I recognise, so should be mostly new faces which is great
19:28:34 <cybette> Hacktoberfest will not be super formal, just a place to gather, especially if have new contributors
19:28:43 <cybette> felixfontein: I'm done, thanks!
19:28:56 <bcoca> or 8 of my aliases ...
19:29:00 <felixfontein> cool! thanks cybette!
19:29:05 <felixfontein> cyberpear: you're up :)
19:29:08 <cyberpear> ran into this when trying to pip install ansible on top of devel branch of ansible-base `ansible 2.10.1 requires ansible-base<2.11,>=2.10.2, but you'll have ansible-base 2.11.0.dev0 which is incompatible`
19:29:29 <cyberpear> I think we're being too strict about requiring "less than 2.11" ansible-base version
19:29:56 <felixfontein> I do remember that we had this discussion before. though I have no idea where and in which context.
19:30:12 <felixfontein> at least then abadger1999 convinced me that this requirement was good IIRC
19:30:20 <cyberpear> I remember a discussion of which minimum version of ansible-base, and we decided "whatever was latest at release time"
19:30:34 <felixfontein> cyberpear: that's true, but there was also another discussion on that upper bound
19:30:46 <cyberpear> I don't recall the max discussion, but maybe I missed it or am just foggy
19:31:00 <felixfontein> abadger1999: do you remember?
19:31:06 <abadger1999> Yeah, I think we do need an upper bound.
19:31:41 <felixfontein> (it was on 2020-09-11 in this channel)
19:31:44 <abadger1999> His a hypothetical.  let's say ansible-base-2.11.0.dev0 eventually becomes ansible-base-3.0 with major backwards incompatibilities.
19:32:20 <abadger1999> If thhe 2.11.0.dev0 version continued to be used in development, documentation wouldn't match.  Any API changes would break plugins and modules, etc.
19:32:57 <abadger1999> So then... what is a good upper bound?  Right now we use, "anything in the present ansible-base stable series".  I think that's definitely safe.
19:33:40 <felixfontein> how about '<3.0' then?
19:33:44 <abadger1999> Could we be more tolerant?  That's hard to say... my 3.0 is a little hyperbolic but the same thing does apply from 2.10.x to 2.11.x.... just that we'd hope the core team is more circumspect in what they'll brea there.
19:34:04 <cyberpear> my preference would be "until we know that 2.11 dev does breaks things, don't conflict with it"
19:34:15 <cyberpear> or like felixfontein says, <3.0
19:34:38 <abadger1999> cyberpear: Adding a new break later might not work well.  For instance, I think you'd end up without getting bugfixes, then.
19:34:45 <cyberpear> most folks won't be using the in-development branch anyway, but why make it harderd to use ACD for those who do?
19:34:58 <felixfontein> cyberpear: the problem with that is that if say ansible-base 2.14 is totally incompatible with modules that work with ansible-base 2.10, we could end up having users who install ansible-2.10 with ansible-base-2.14, and have a broken system
19:35:30 <cyberpear> right, I'd add the max version when we discover it's needed
19:36:10 <felixfontein> then it might be too late because people restricted their ansible version to something older, that doesn't have the ansible-base max restriction yet
19:36:23 <abadger1999> (i have ansible-base-2.11.0b1 installed as a dep for ansible-2.10.19.  Then ansible-2.10.20 decreases its dep to ansible-base<2.11.  Then you end up with the ansible-base that's installed conflicting with any new ansible packages0
19:36:27 <felixfontein> (I wish ansible-lint wouldn't depend on ansible, that currently totally screws me)
19:36:45 <abadger1999> Documentation also gets out of sync.
19:37:12 <felixfontein> cyberpear: out of curiosity, are you asking this because of ansible-lint?
19:37:45 <abadger1999> Anyhow... what we have now is safe.  I don't think increasing can be safe.  But I don't know if some other concern is more important than safe.
19:38:20 <cyberpear> no, I was trying to install "ansible" on top of ansible-base development version
19:38:34 <cyberpear> but sounds like it was deliberate... just annoying to run into it.
19:38:41 <bcoca> option to ignore, up to user if 'they know better'
19:38:41 <abadger1999> (I'd like acozine to be present to discuss if we do decide we want to  make a change to this [see the documentation syncing issue mentioned above])
19:38:53 <cyberpear> we can move on to other topics if people have them
19:39:15 <cyberpear> (or end since we're over time)
19:39:17 <abadger1999> cyberpear: would ansible nightlies help?
19:40:06 <felixfontein> or a ansible meta-collection which depends on the precise versions of all collections that are included in ansible
19:40:10 <abadger1999> That's a thing that should go on the agenda at some point.  webknjaz has a github action to build nightlies.  It seems like a good idea in theory.  I just want details to get ironed out... for instance, what github-based url should the nightlies live at.
19:40:11 <cyberpear> abadger1999: I'm `pip install ~/path/to/ansible-base` git repo where I'm making local changes for testing
19:40:24 <cyberpear> but nightly could be very helpful for CI jobs
19:40:43 <gundalow> #info Galaxy team are looking at `ansible-galaxy collection install` timeouts. Appears someone is hammering the galaxy.ansible.com on the hour every hour
19:40:55 <cyberpear> IIRC there was a discussion in the core meeting about an alternative binary name for a nightly install to be co-installed w/ stable ansible
19:41:08 <abadger1999> cyberpear: <nod> You'd have to install the ansible nightly.  Then you'd be able to install ansible-base from a git repo.  (at least, that's the theory.  I ahven't tried it yet)
19:41:09 <felixfontein> gundalow: sounds like some CI running on cron schedule
19:41:49 <cyberpear> abadger1999: I see what you're saying, have an "ansible (ACD) nightly" without the version constraint
19:41:50 <abadger1999> cyberpear: there is talk about "ansible-chaos" which is something like that..... Maybe more like a branch with experimental features.
19:41:55 <abadger1999> cyberpear: yep.
19:42:01 <cyberpear> that would be helpful, yes
19:42:42 <gundalow> cyberpear: name will be discussed in tomorrow's Core meeting, possibly `pip install fallible`, so `fallible-playbook`
19:43:15 <abadger1999> Here's webknjaz's PR: https://github.com/ansible-community/antsibull/pull/195  Like I say, I like the idea but want details to be decided before merging and enabling it.
19:43:16 <github-linkbot> https://github.com/ansible-community/antsibull/pull/195 | open, created 2020-09-30T18:02:11Z by webknjaz: Add a workflow building nightlies
19:47:48 <felixfontein> ok. should we stop for today?
19:47:52 <felixfontein> it's almost two hours
19:48:11 <cybette> I think it's a good time to stop
19:48:14 <gundalow> I don't think I have brain for anything else today
19:48:25 <felixfontein> sounds good.
19:48:27 <gundalow> (which was probs true about 3 hours ago)
19:48:34 <felixfontein> :)
19:48:36 <felixfontein> #endmeeting