19:01:25 #startmeeting Ansible Community Meeting 19:01:25 Meeting started Wed Feb 24 19:01:25 2021 UTC. 19:01:25 This meeting is logged and archived in a public location. 19:01:25 The chair is dmsimard. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:25 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:01:25 The meeting name has been set to 'ansible_community_meeting' 19:01:28 o/ 19:01:39 #topic Agenda https://github.com/ansible/community/issues/539 19:01:45 o/ 19:01:50 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:01:54 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:01:57 hah 19:01:59 :) 19:02:04 * dericcrago waves 19:02:08 can you chair some people? 19:02:12 o/ 19:02:17 #chair felixfontein jillr andersson007_ dericcrago acozine 19:02:17 Current chairs: acozine andersson007_ dericcrago dmsimard felixfontein jillr 19:02:21 #topic Updates 19:02:21 #info Ansible 3.0.0 has been released! \o/ 19:02:21 #info docsite split began: https://docs.ansible.com/ansible/latest/ is Ansible 3, https://docs.ansible.com/ansible/2.10/ is Ansible 2.10 (not yet updated), https://docs.ansible.com/ansible-core/devel/ is ansible-core 19:02:26 thanks :) 19:03:02 Hello :) 19:03:12 * tadeboro waves o/ 19:03:14 #chair lmodemal tadeboro 19:03:14 Current chairs: acozine andersson007_ dericcrago dmsimard felixfontein jillr lmodemal tadeboro 19:03:59 I suggest starting from adding https://github.com/ansible-collections/overview/pull/157 . it shouldn't take a lot of time 19:04:15 Sorry, heading to the Zoo with the kids today! 19:04:17 andersson007_: I disagree 19:04:29 felixfontein: why?:) 19:04:32 I think we should first find out what we already discussed and decided on that topic before opening it again :) 19:04:37 see my comment in that issue 19:05:11 ok, no problem! 19:05:15 #info Contributor summit in ~two weeks, register if you haven't https://www.eventbrite.com/e/ansible-contributor-summit-202103-registration-141735886853 and check out topics on https://hackmd.io/uZDSLOOdS1Kx0xfZVIATmQ 19:05:33 geerlingguy: have fun! 19:05:39 geerlingguy: enjoy! 19:06:05 any other updates/announcements ? 19:07:07 ah, hang on 19:07:47 They weren't published in time before the last meeting, if you haven't had the chance to look at them there are blog posts about 3.0.0 as well as a Q&A 19:07:56 #link https://www.ansible.com/blog/announcing-the-community-ansible-3.0.0-package 19:07:57 (felixfontein i meant adding the note, not split of collections and tests) 19:08:00 * samccann strolls in late 19:08:01 #link https://www.ansible.com/blog/ansible-3.0.0-qa 19:08:14 #chair samccann 19:08:14 Current chairs: acozine andersson007_ dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro 19:08:35 andersson007_: ah, ok, that should be fine! 19:08:39 #link https://blog.while-true-do.io/ansible-release-3-0-0/ 19:08:50 ^ daniel_wtd also put out a blog post which is a nice read :) 19:08:50 felixfontein: cool:) 19:09:09 that's it for me 19:09:39 #topic Add a requirement not to store package installers and other large objects used for integration tests 19:09:42 #link https://github.com/ansible-collections/overview/pull/157 19:09:43 andersson007_: do you want to present this? 19:10:33 i suggest adding a requirement not to store package installers and other large objects used for integration tests. 19:10:33 The current collection tarball size limit to upload to galaxy is 20MB. 19:10:33 When a number of collection increases, it can affect Ansible distribution size significantly. 19:10:44 I just copy-pasted:) 19:12:32 I'm +1 on collections not storing large (though we should define "large") artifacts or binaries, regardless if they're test related or not 19:12:36 most changes in the PR are unrelated to the PR, in case anyone wonders why there is so much diff: https://github.com/ansible-collections/overview/pull/157/files 19:12:50 like, pretend there's a role that has a .tar.gz in the "files" directory 19:12:56 (my messages disappear during the day) 19:13:02 (here) 19:13:07 roles/foo/files/some_large_thing.tar.gz 19:13:08 hey folks 19:13:13 I am a bit torn on this one. I usually start tinkering with a new project by running its test suite. 19:13:28 #chair briantist 19:13:28 Current chairs: acozine andersson007_ briantist dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro 19:13:44 tadeboro: this is not about removing tests, just about making sure that tests/ does not contain large binaries (which can also be hosted somewhere else) 19:13:52 I do not mind not packaging things into galaxy artifacts, but removing them from repo itself does not sound right. 19:15:14 it's probably better to make progress on packaging tests into a separate package (when talking about the Ansible package), then this is not really a big problem anyway 19:15:29 So, politely asking authors to find another way is OK, but demanding that they drop the files is -1 from me. 19:15:35 I can see this being an issue for non-test related stuff too 19:15:47 when I was younger i put an installer in tests in ansible/ansible. Folks from core explained to me that it's not a good idea 19:16:30 Well, putting thins in repo is a compromise, just like downloading stuff at test time. 19:17:02 as far as i know there's a dedicated aws instance for such objects if really needed 19:17:15 for me, beyond the file size concern, putting some of that stuff into repo (like outside binaries) also felt wrong to me from a licensing perspective, but I don't know enough about that 19:17:47 +1 to concerns about licensing 19:18:10 cybette-clock says we're 18 minutes into the meeting and 9 minutes into "Add a requirement not to store package installers and other large objects used for integration tests" 19:18:17 andersson007_: But I guess not all collection maintainers have access to such resources. Community is more than what is partially-supported by Red Hat. 19:18:25 if it's a 'random' binary, does that mean it could potentially be used by ..nefarious people for nefarious (aka security hacking) purposes? 19:19:11 binaries (or to a lesser extent, archives) are compiled and can originate from a project with different licensing 19:19:16 as in someone takes a not-well-maintained collection, plops a bad binary in there, updates the collection version etc (does all the other right stuff) and we have a problem? 19:19:34 samccann: I think that can already be done with regular Python scripts 19:19:58 felixfontein - so is that a good or bad thing? and if bad, are we making it even worse? 19:20:00 We already package content based on trust. So not much changes in this respect here. 19:20:26 yeah I guess the rest of the content is 'readable' by humans though. binaries seem different 19:20:41 samccann: I think we're not making it worse by not requiring to not include 'random' binaries 19:20:58 right exactly, I don't think binaries change the security landscape much, I was more referring to what dmsimard mentioned. We have a specific license for content in the repo. Bringing in outside content, without noting what license applies to it, seems problematic? 19:21:12 tadeboro: i think if someone really needs to store something inside tests/ we could discuss. I suggest a default rule 19:21:32 briantist: adding stuff with a non-compatible license can be a problem, especially when that binary is included in the collection artefact 19:21:46 what I'm saying also applies to non-binary stuff, it's just we tend to think about it more when we're bringing in source 19:22:08 andersson007_: I do not mind the goal of the rule, but that MUST is a bit too much for my taste. 19:22:15 https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#licensing says that everything in the collection artefact must be licensed under GPLv3+, except possibly module_utils (which also allows BSD-2-clause) 19:22:16 given cisco.nxos is number 2, with 8.2M, we just have a lot of tests. no binaries 19:25:56 ok, so we should find out what we actually want :) 19:26:22 is the general goal here to reduce the size of the Ansible community package? 19:26:29 I think the long-term goal of moving tests/ into its own distriution package is something that would solve most issues 19:26:31 I suggest we table this one for now until we find out whether or not we can exclude tests from the tarball 19:26:52 if someone wants to volunteer working on that, it would definitely happen sooner :) 19:28:28 I can hunt it down and follow up with gundalow and abadger1999 on the legal aspect of it 19:29:13 I think the main legal problem was removing them without packaging them in a separate package, so if we have a mechanism to create a tests-only package, it should get a lot easier 19:29:42 It's standard practice to ship tests in subpackages in RPM land but I don't recall seeing something like that on pypi 19:29:48 #action dmsimard hunt down and follow up with gundalow and abadger1999 on the legal aspect of moving tests to separate package / removing from main package 19:29:54 not that we can't do it but I've never seen it 19:30:11 As I said, I am all for reducing the size of the ansible PyPI package, but the current proposal seems to try to achive that in a non-optimal way. 19:30:12 I guess the main reason is that usually tests are not THAT a large part of the whole package 19:30:40 Imposing restrictions tends to make people test even less ;) 19:30:55 should we discuss a similar rule for plugins/ itself, or generally outside tests/ and docs/? 19:31:09 true story 19:31:24 or some kind of system where collections have to ask for allowance if they want to include a large binary outside of tests/ and docs/? 19:31:42 (since that are parts of collections we don't plan on removing) 19:31:42 felixfontein: if I submit a role to community.general that has roles/files/archive.tar.gz with 50MB, that's not OK 19:32:00 if you remove tests from pypi, it also means collections owners need another step to maybe debug a problem. Given, asking a user to run tests, is a way to debug things 19:32:15 yeah, what sort of binaries are we talking about here - methinks binaries in general are likely not ok 19:32:21 I would say, removing tarballs / artifacts should be encouraged, deleting the tests folder not so much 19:32:22 dmsimard: true, but if you do that for collection dmsimard.tools that's already included in Ansible 3, nobody can really stop you from doing it right now 19:32:49 I think I agree with tadeboro about the MUST, no doubt it should be discouraged, but saying never seems a little too far 19:33:11 pabelanger: I would only remove them if there is another artefact that includes all tests 19:33:12 odyssey4me: context is that we mistakenly ended up packaging a bunch of test fixtures that weighed down the package and we'd like to keep that in check 19:33:35 dmsimard: a rule won't prevent accidents :) 19:33:41 We also packaged venv once IIRC, sooo yeah ;) 19:33:43 maybe just a CI check with a specific override file for allowances? 19:34:15 ie fail the check by default, but we have a list of files which are allowed (with commit msgs for record) 19:34:26 odyssey4me: sounds like a good idea 19:34:44 but it also does not protect from packaging errors 19:34:47 I don't think we should modify a collection, if we think a collection is too big, we should work with the collection owner to exclude the content to start with. I also agree, if you are going to cap tests due to the size, you'll likely end up with people not writing tests 19:35:01 in the case dmsimard mentioned the large binary was added during collection building, it was not part of the repository 19:35:16 pabelanger: fwiw galaxy has a hard cap at 20MB so we're "protected" to a certain extent 19:35:26 ah, and in most cases this will be a mistake - not an intention 19:36:32 I like odyssey4me 's idea. A test that fails on any file of a certain size, with a way to add ignores. It really helps with the fact, as you said, in most cases this is a mistake 19:36:39 (or maybe oversight is a better word) 19:37:14 I think that also needs to be discussed with the core team / mattclay if we want such a test in `ansible-test sanity` 19:37:15 cybette-clock says we're 37 minutes into the meeting and 26 minutes into "Add a requirement not to store package installers and other large objects used for integration tests" 19:37:30 felixfontein++ 19:37:33 also we have to talk about the size limit first :) 19:37:35 do we have a max_total_size in mind that we want to stay under for the PyPI package? maybe we could implement odyssey4me's idea and then revisit in six months or if the package approaches that max size? 19:37:54 we can check this at build/release time, checking this for 80+ individual collections that are not all under our control is not trivial 19:38:09 I mean, from a CI perspective 19:38:27 acozine: that's pretty much impossible to implement - we need some explicit steps to take if the package exceeds that limit. should we throw random collections out and screw users? restrict collections to older versions and prohibit bugfixes/new features to go in? 19:38:50 dmsimard: checking at build/release is usually too late somewhat :) 19:39:14 dmsimard: either it delays the release, or we stop updating a collection (with potential bad side effects) 19:39:30 I plan on running the build/release process far more often than it does currently 19:39:34 i.e, not just at release time 19:39:56 not to cut new releases, but to test continuously that nothing has broken so we're not stranded on release day 19:40:05 you know, CI :) 19:40:26 maybe we should start monitoring file sizes in collection artefacts, have some stats on that, and then we can continue discussing this 19:40:32 +1 19:40:45 does anyone want to start compiling such stats? 19:41:06 * tadeboro hides 19:41:09 :) 19:41:14 * felixfontein too, too much other things on my plate 19:41:38 that seems like the perfect thing for a nightly job to do 19:41:42 I did download the galaxy once, I do not intend on doing that anytime soon ;) 19:41:51 and it looks like dmsimard already plans to do so ;) 19:42:01 hehe 19:42:27 I can take it 19:42:37 keep in mind, collections also publish to automation hub, so I know we wouldn't what to support 2 different file-size limits 19:42:38 maybe not by next week but I've already done part of that work in that PR 19:42:51 ok, good :) 19:42:55 thanks dmsimard! 19:43:09 thanks dmsimard - appreciate it... 19:43:14 pabelanger: does AH have a file size limit? 19:43:22 unknown 19:43:22 what will we do with the PR: 1) change MUST to SHOULD 2) close the pr? 19:44:00 andersson007_: probably it's best to split the editorial changes into another PR so they are not lost :) 19:44:32 andersson007_: about the main change, I'm not sure. adjusting it to SHOULD with more precise guidelines (that need more discussions in future meetings, once we have stats) is probably a good idea 19:44:59 is abadger1999 around btw? 19:45:12 I htink he's on PTO 19:45:12 (or does someone know he definitely won't be around for this meeting?) 19:45:15 ah 19:45:24 I would go with SHOULD because it is still a sane advice. And this gives reviewer a chance to start talking with maintainers about the good practices and what to do to get thing in a better shape. 19:45:29 I'd suggest to skip the Python version requirements topic to next week then (when he's back) 19:46:10 SHOULD works for me 19:46:42 andersson007_: can you change it to SHOULD and extend it to all files in the collection (and not just tests/integration/)? 19:46:51 because we don't want large files in other directories as well :) 19:47:06 felixfontein: sure, right now? 19:47:32 andersson007_: no, let's discuss it another time 19:47:48 felixfontein: cool, ok 19:48:50 we have some more topics that are not urgent: 1) docs for latest collection releases on docs.ansible.com (which also belongs into the DaWGs realm), 2) new content for community.general (and I guess community.network), 3) https://github.com/Andersson007/ansible_reviewer vs integration with ansible-test sanity, 4) require deprecation ahead of breaking changes 19:48:50 sopmething I just thought of given pabelanger's comment about test inclusion being useful would be to have guidance for excluding something from a collection build 19:49:13 in some cases a collection owner may choose to exclude tests because they are not useful outside of the CI 19:49:17 odyssey4me: please add a comment/suggestion to that PR :) 19:49:51 has anyone a preference for one of these topics? otherwise I'd suggest to continue with 2) 19:49:54 okey dokey 19:50:14 odyssey4me: yes, if collection owners don't want to ship them by default, they totally should and can exclude them at collection build time 19:50:44 felixfontein: 2 is too controversial imo 19:51:03 without abadger1999 and gundalow 19:51:35 we should dedicate a special session for that:) 19:51:45 I added 1 (docs for latest collections) to the DaWGs agenda for next week so we don't forget 19:51:50 ok, fine for me 19:51:58 samccann: sounds good! 19:52:00 would also need abadger's help tho to implement whatever we decide 19:52:29 the "docs for latest collections" is basically "devel docs for the community package", right? 19:52:30 true. we can still discuss what 'community' wants :) 19:52:42 acozine: not necessarily, but almost :) 19:52:54 I mean, we would publish them as `devel` 19:53:00 maybe let's talk about that quickly, and see whether we want to defer this competely to the DaWGs meeting or not 19:53:03 #topic Users seem to expect that docs.ansible.com shows latest docs for collections released on galaxy (https://github.com/ansible/community/issues/539#issuecomment-778847740) 19:53:07 #info Idea: Separate per-collection docsites for included collections on docs.ansible.com (or somewhere else)? 19:53:10 #info Idea: Ansible devel docs: could contain docs for latest release (or also pre-releases) on galaxy? (Has been discussed in DaWGs meeting) 19:53:31 the second idea is what we discussed quickly in the DaWGs meeting 19:54:11 the question on wether devel should include prereleases or not can be important here, if someone wants to have docs for the latest stable release of a collection, devel won't help (assuming there are newer prereleases) 19:54:35 tadeboro originally came up with the question (I think based on user feedback) 19:54:39 Yeah I can see docs.ansible.com/ansible/devel/ pulling in the most recent collection version from galaxy, for collections within Ansible the package 19:56:05 so my leaning is toward /ansible/devel/ being ...devel for Ansible the package 19:56:14 having one docsite per collection contained in Ansible is a lot of work to maintain, I'm not sure whether the Ansible community team actually wants to host that or invest time/money in that 19:56:30 So if we spun it up today, it would be the 3.0 collection list, but no versions (so it grabs whatever is the most recent) 19:56:36 having /ansible/devel/ with prereleases solves most issues, at least for collections which don't do prereleases :) 19:57:12 felixfontein - can you explain prereleases? is this like 2.0.0.1b or something funky like that? 19:57:16 are there more ideas / wishes / caveats anyone can think of? 19:57:17 or 0.0.0.1b 19:57:27 samccann: yes, like 2.0.0-alpha 19:57:38 I like that idea 19:57:50 as long as they get onto Galaxy, I think we can pull them based on upload date/time 19:57:52 samccann: if /ansible/devel/ contains the 2.0.0-alpha docs for a collection long before 2.0.0 is released, this can be very confusing for customers which expect stable docs 19:57:58 s/customers/users/ :) 19:58:05 I wonder whether the same process that builds that could also build test the collection and find other issues to notify the owner 19:58:05 devel isn't stable docs tho 19:58:25 if they want stable, they should use the package 19:58:26 I see two requests here - one is a 'devel' for Ansible the package 19:58:35 samccann: it isn't, but if we do not include prereleases, it would essentially be stable docs of collections - but not stable docs of ansible-core :) 19:58:38 the other is /latest/ for collections 19:58:42 cybette-clock says we're 58 minutes into the meeting and 5 minutes into the topic 19:59:04 I like how dmsimard is using the cybette-clock :) 19:59:21 heh 19:59:38 ok maybe we take a step back.. put on our imaginary use hats 19:59:38 devel vs latest, I like that too personally 19:59:43 * dmsimard is cybette-clock by interim 19:59:57 I don't think we can do two different types of /latest/ docs 20:00:08 I use foo collection. I have Ansible the package. I get the docs on /latest/ today 20:00:31 acozine: I tihnk we can only have two different kind of /latest/ docs if we have separate docsites for collections 20:00:36 I use foo collection, I've updated it locally to 2.0.0 (not in Ansible package today). I can't find docs except in github 20:00:39 (community user) 20:00:42 acozine: but that's something that eats a lot of resources 20:01:07 it's also very confusing for search engines 20:01:27 we'd have https://docs.ansible.com/ansible/latest/collections/ansible/posix/index.html#plugins-in-ansible-posix 20:01:57 and then we'd also have some other URL that also looks like the "latest" version of ansible.posix? 20:02:05 * tadeboro needs to leave. Will read meetings logs later. 20:02:08 indeed, it is 20:02:10 bye tadeboro! 20:02:20 +1 20:02:21 tadeboro: have a good evening 20:02:39 Ok so if the priority is 'give me the latest stable collection version, in docs' Then we could do that with /devel/ 20:02:46 and not includ prereleases 20:03:06 another option is a URL parameter - /latest/&devel=true or some such 20:03:15 that way the search engin4es don't get hurt 20:03:29 odyssey4me: that would require some code instead of static pages that are served 20:03:51 right now the docsite is static pages that are served, which makes it pretty fast 20:04:10 I don't think it's a good idea to change that, except if someone wants to provide a lot of money for the resources needed :) 20:04:21 fair enough - if url rewriting is an option, that would do it too... but fair enough 20:04:48 the advantage of the current system is that for 80% of users it works - most people want to see the docs for the collections that are included in the Ansible community package they have installed right now 20:05:04 and `latest` should continue to mean that ^^^ 20:05:38 hmm, I'm not 100% sure on that - a lot of people are also using ansible 2.9 (in tower for example) and have to install collections manually 20:06:04 for all these, /ansible/latest/ is not really relevant and can provide docs that are out of date 20:06:11 we can use `devel` for "most recent releases since the last package release" 20:06:12 Tower as official Tower (not awx) - users would I think have paid for Automation Hub and that has the module docs 20:06:21 even then, different versions of the package will carry different version of the collections 20:06:47 in any case, it's quite a mess :) 20:07:11 I'm happy with /ansible/latest/ and /ansible/devel/ where devel has the latest releases 20:07:20 +1 20:07:24 what's the opinion of folks here on whether /devel/ should include prereleases? 20:07:27 +1 20:07:46 (er, that +1 was not for pre-releases) 20:07:47 I'm inclined to vote no on prereleases 20:08:27 because that has some impact on whether /devel/ does the job of providing the latest collection release (without "pre") docs for collections or not 20:08:36 i realize that means we aren't quite 'devel' in the purest sense, but we can't cover it all. I'd rather see us go for the most common use case, and that seems to be the most recent stable collection 20:08:52 samccann: I'm currently tending that way as well 20:09:04 are there other opinions on this? 20:09:13 I don't think providing pre-releases are necessary, you aren't going to accidently install a pre-release so I think it's reasonable that you can find that documentation on your own 20:09:14 what is a pre-release ? 20:09:30 :D 20:09:31 a collection version that is released but isn't yet included in the latest ansible package ? 20:09:32 dmsimard: like an alpha or beta release of a colleciton, or a release candidate 20:09:44 look at https://semver.org/ for an exact definition :) 20:10:04 if a collection version has a pre-release specifier, it is a pre-release 20:10:15 whatever that means precisely depends on the collection and maybe even collection version 20:10:17 dmsimard: there can be full releases that are not yet included in the latest ansible package 20:10:23 * lmodemal logging off for the day :) 20:10:29 lmodemal: bye! 20:10:32 lmodemal: bye! 20:10:55 what dmsimard has asked is actually a good one 20:10:57 acozine: these are not pre-releases 20:11:23 that's what I meant, they are full releases 20:11:26 I've seen some collections use dev releases (I wanna say published to galaxy through zuul?) but it's not very common that I know of 20:11:26 would /devel include pre-release docs which aren't from alpha/beta packages... but have been released but aren't in the ansible package yet 20:11:43 dmsimard: these are pre-releases for example 20:11:51 collections can also have beta or alpha or release candidates 20:11:58 these would be pre-releases as well 20:12:16 surely including whatever is the latest actual release in the docs is fine ? 20:12:19 odyssey4me: that are not pre-releases 20:12:24 rather than needing the logic to handle pre-releases 20:12:25 odyssey4me: yes 20:12:27 odyssey4me: that are releases not included in ansible yet 20:12:48 we should not start mixing well-defined terminology :) 20:12:54 yep, so what is the intent of /devel - to share docs from collections not in ansible yet, or something else? 20:12:56 dmsimard - depends on what problem we are solving 20:13:15 odessey4me - that's what we are trying to decide 20:13:25 odyssey4me: traditionally /devel/ contained the docs from ansible/ansible's devel branch, which is essentially a pre-release 20:13:41 (of the next ansible-core 'major' release) 20:13:45 either we are full-on devel and accept prereleases, or we are 'most recent stable collections' for users who get them from galaxy but aren't yet in Ansible 20:14:01 but in the collection world, we need to redefine what /devel/ contains next to the ansible-core pre-release 20:14:09 cybette-clock says we're 74 minutes into the meeting and 20 minutes into the topic 20:14:33 I don't feel strongly either way, but I think there may be some merit to including docs from collections which haven't been packaged with ansible yet. 20:14:35 for me the 'most recent stable collections' is the more important problem to solve since users can't find those module docs anywhere on Galaxy today. They'd have to go read the github repo python files 20:14:35 samccann: both is fine for me, and both has different pros and cons 20:14:46 samccann: +1 20:14:57 samccann yep, that's what I mean +1 20:15:04 samccann: +1 20:15:12 odyseey4me - so far, we aren't including collections not in Ansible (at least not until they are accepted into Ansible for a future release) 20:15:24 we cam 20:15:28 erg 20:15:48 we can't publish docs for every single version of every single collection on Galaxy 20:15:59 samccann oh, I think that's a misunderstanding - I meant collections approved for the next release... not every collection on the planet 20:16:06 phew 20:16:08 :-) 20:16:10 (or other planets) :) 20:16:14 :) 20:16:18 mars collection!!! 20:16:26 I mean, we gotta start thinking about mars, right? :) 20:16:28 yeah, that's either something galaxy has to do, or something that a collection has to do for itself 20:16:36 dammit, you beat me 20:16:42 creating your own docsite for a collection isn't that hard 20:16:49 so we're limiting it to collections in the most recent package release (`latest`) and the later versions of those same collections (`devel`) 20:17:05 ok so are we ready to vote on ansible /devel/ docs will not include prerelease? 20:17:19 acozine yes, that sounds correct 20:17:32 acozine: not sure 20:17:52 I mean if there is a collection data file for Ansible 4, do we then start publishing that to /devel/? 20:17:55 VOTE: should /ansible/devel/ use (a) the latest pre-releases of a collection, or (b) just the latest 'stable' releases? 20:18:03 b 20:18:07 b 20:18:07 b 20:18:07 b 20:18:16 b 20:18:23 b 20:18:32 b 20:18:58 /devel/ is usually updated daily, so there will be a few hours when the docs for the latest release aren't there, but it will only be max ~24 hours :) 20:19:38 though we have not yet implemented this, so . . . it will be a few days/weeks before it shows up at all 20:19:44 true :) 20:19:57 just managing expectations a little ;-) 20:20:11 #agreed /ansible/devel/ should use the latest 'stable' releases (and not pre-releases) 20:20:42 true :) it needs to be implemented first, but at least now it's clear what exactly should be implemented :) 20:20:48 yay! 20:21:48 * acozine must go to prepare for next meeting at the half-hour 20:22:00 ok, is anyone interested in discussing some more topics, or should we stop 'early' today? :) 20:22:05 (just 1 h 22 min ;) ) 20:22:10 we're running on almost 90 minutes and the objective was to end before 20:22:16 we can open up the floor if there are no other topics 20:22:34 dmsimard: was that an objective? :) 20:22:40 #topic open floor 20:22:43 I said it was before the meeting :D 20:22:48 does anyone has something that should be discussed now? 20:22:58 (if you have something for the next meetings, just put it on the agenda!) 20:23:03 dmsimard: ok :D 20:23:20 where does the agenda for this meeting live? 20:23:31 https://github.com/ansible/community/issues/539 20:23:32 https://github.com/ansible/community/issues/539 20:23:55 dmsimard: what happened to github-linkbot btw 20:24:06 #info add topics to the agenda for this community meeting at https://github.com/ansible/community/issues/539 20:24:14 thanks 20:24:21 felixfontein: it's alive but only expands PRs for now 20:24:26 ah, right 20:24:29 I meant to add support for issues too but haven't got around to it 20:24:57 dmsimard: it did ignore a pull request URL today though 20:24:57 it's in my flaming pile of TODOs :) 20:24:58 https://github.com/ansible-collections/overview/pull/157 20:25:10 ah, I'll figure out why, thanks 20:25:19 ah, because it was the last one used.... 20:25:23 (before the meeting :) ) 20:25:30 and we had no other PR link during the meeting 20:25:34 oh, it does keep a memory of the links that were expanded recently 20:25:39 doesn't happen that often ;) 20:25:44 * samccann needs to drop 20:25:46 it's not time-limited though 20:25:54 samccann: o/ thanks for coming 20:25:57 #unchair samccann 20:25:57 Current chairs: acozine andersson007_ briantist dericcrago dmsimard felixfontein jillr lmodemal tadeboro 20:26:04 I think we're good, thanks for coming everyone :) 20:26:17 odyssey4me: thanks for joining us, appreciate it <3 20:26:40 thanks folks! 20:26:41 #endmeeting