19:01:25 <dmsimard> #startmeeting Ansible Community Meeting
19:01:25 <zodbot> Meeting started Wed Feb 24 19:01:25 2021 UTC.
19:01:25 <zodbot> This meeting is logged and archived in a public location.
19:01:25 <zodbot> The chair is dmsimard. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:25 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:01:28 <jillr> o/
19:01:39 <dmsimard> #topic Agenda https://github.com/ansible/community/issues/539
19:01:45 <felixfontein> o/
19:01:50 <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:01:54 <dmsimard> 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 <dmsimard> hah
19:01:59 <felixfontein> :)
19:02:04 * dericcrago waves
19:02:08 <felixfontein> can you chair some people?
19:02:12 <acozine> o/
19:02:17 <dmsimard> #chair felixfontein jillr andersson007_ dericcrago acozine
19:02:17 <zodbot> Current chairs: acozine andersson007_ dericcrago dmsimard felixfontein jillr
19:02:21 <felixfontein> #topic Updates
19:02:21 <felixfontein> #info Ansible 3.0.0 has been released! \o/
19:02:21 <felixfontein> #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 <felixfontein> thanks :)
19:03:02 <lmodemal> Hello :)
19:03:12 * tadeboro waves o/
19:03:14 <felixfontein> #chair lmodemal tadeboro
19:03:14 <zodbot> Current chairs: acozine andersson007_ dericcrago dmsimard felixfontein jillr lmodemal tadeboro
19:03:59 <andersson007_> I suggest starting from adding https://github.com/ansible-collections/overview/pull/157 . it shouldn't take a lot of time
19:04:15 <geerlingguy> Sorry, heading to the Zoo with the kids today!
19:04:17 <felixfontein> andersson007_: I disagree
19:04:29 <andersson007_> felixfontein: why?:)
19:04:32 <felixfontein> I think we should first find out what we already discussed and decided on that topic before opening it again :)
19:04:37 <felixfontein> see my comment in that issue
19:05:11 <andersson007_> ok, no problem!
19:05:15 <dmsimard> #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 <dmsimard> geerlingguy: have fun!
19:05:39 <felixfontein> geerlingguy: enjoy!
19:06:05 <dmsimard> any other updates/announcements ?
19:07:07 <dmsimard> ah, hang on
19:07:47 <dmsimard> 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 <dmsimard> #link https://www.ansible.com/blog/announcing-the-community-ansible-3.0.0-package
19:07:57 <andersson007_> (felixfontein i meant adding the note, not split of collections and tests)
19:08:00 * samccann strolls in late
19:08:01 <dmsimard> #link https://www.ansible.com/blog/ansible-3.0.0-qa
19:08:14 <felixfontein> #chair samccann
19:08:14 <zodbot> Current chairs: acozine andersson007_ dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro
19:08:35 <felixfontein> andersson007_: ah, ok, that should be fine!
19:08:39 <dmsimard> #link https://blog.while-true-do.io/ansible-release-3-0-0/
19:08:50 <dmsimard> ^ daniel_wtd also put out a blog post which is a nice read :)
19:08:50 <andersson007_> felixfontein: cool:)
19:09:09 <dmsimard> that's it for me
19:09:39 <felixfontein> #topic Add a requirement not to store package installers and other large objects used for integration tests
19:09:42 <felixfontein> #link https://github.com/ansible-collections/overview/pull/157
19:09:43 <felixfontein> andersson007_: do you want to present this?
19:10:33 <andersson007_> i suggest adding a requirement not to store package installers and other large objects used for integration tests.
19:10:33 <andersson007_> The current collection tarball size limit to upload to galaxy is 20MB.
19:10:33 <andersson007_> When a number of collection increases, it can affect Ansible distribution size significantly.
19:10:44 <andersson007_> I just copy-pasted:)
19:12:32 <dmsimard> 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 <felixfontein> 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 <dmsimard> like, pretend there's a role that has a .tar.gz in the "files" directory
19:12:56 <andersson007_> (my messages disappear during the day)
19:13:02 <andersson007_> (here)
19:13:07 <dmsimard> roles/foo/files/some_large_thing.tar.gz
19:13:08 <briantist> hey folks
19:13:13 <tadeboro> I am a bit torn on this one. I usually start tinkering with a new project by running its test suite.
19:13:28 <felixfontein> #chair briantist
19:13:28 <zodbot> Current chairs: acozine andersson007_ briantist dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro
19:13:44 <felixfontein> 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 <tadeboro> I do not mind not packaging things into galaxy artifacts, but removing them from repo itself does not sound right.
19:15:14 <felixfontein> 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 <tadeboro> So, politely asking authors to find another way is OK, but demanding that they drop the files is -1 from me.
19:15:35 <dmsimard> I can see this being an issue for non-test related stuff too
19:15:47 <andersson007_> 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 <tadeboro> Well, putting thins in repo is a compromise, just like downloading stuff at test time.
19:17:02 <andersson007_> as far as i know there's a dedicated aws instance for such objects if really needed
19:17:15 <briantist> 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 <andersson007_> +1 to concerns about licensing
19:18:10 <dmsimard> 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 <tadeboro> 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 <samccann> 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 <dmsimard> binaries (or to a lesser extent, archives) are compiled and can originate from a project with different licensing
19:19:16 <samccann> 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 <felixfontein> samccann: I think that can already be done with regular Python scripts
19:19:58 <samccann> felixfontein - so is that a good or bad thing? and if bad, are we making it even worse?
19:20:00 <tadeboro> We already package content based on trust. So not much changes in this respect here.
19:20:26 <samccann> yeah I guess the rest of the content is 'readable' by humans though. binaries seem different
19:20:41 <felixfontein> samccann: I think we're not making it worse by not requiring to not include 'random' binaries
19:20:58 <briantist> 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 <andersson007_> tadeboro: i think if someone really needs to store something inside tests/ we could discuss. I suggest a default rule
19:21:32 <felixfontein> 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 <briantist> 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 <tadeboro> andersson007_: I do not mind the goal of the rule, but that MUST is a bit too much for my taste.
19:22:15 <felixfontein> 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 <pabelanger> given cisco.nxos is number 2, with 8.2M, we just have a lot of tests. no binaries
19:25:56 <felixfontein> ok, so we should find out what we actually want :)
19:26:22 <acozine> is the general goal here to reduce the size of the Ansible community package?
19:26:29 <felixfontein> I think the long-term goal of moving tests/ into its own distriution package is something that would solve most issues
19:26:31 <dmsimard> 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 <felixfontein> if someone wants to volunteer working on that, it would definitely happen sooner :)
19:28:28 <dmsimard> I can hunt it down and follow up with gundalow and abadger1999 on the legal aspect of it
19:29:13 <felixfontein> 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 <dmsimard> 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 <felixfontein> #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 <dmsimard> not that we can't do it but I've never seen it
19:30:11 <tadeboro> 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 <felixfontein> I guess the main reason is that usually tests are not THAT a large part of the whole package
19:30:40 <tadeboro> Imposing restrictions tends to make people test even less ;)
19:30:55 <felixfontein> should we discuss a similar rule for plugins/ itself, or generally outside tests/ and docs/?
19:31:09 <odyssey4me> true story
19:31:24 <felixfontein> 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 <felixfontein> (since that are parts of collections we don't plan on removing)
19:31:42 <dmsimard> 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 <pabelanger> 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 <odyssey4me> yeah, what sort of binaries are we talking about here - methinks binaries in general are likely not ok
19:32:21 <pabelanger> I would say, removing tarballs / artifacts should be encouraged, deleting the tests folder not so much
19:32:22 <felixfontein> 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 <briantist> 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 <felixfontein> pabelanger: I would only remove them if there is another artefact that includes all tests
19:33:12 <dmsimard> 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 <felixfontein> dmsimard: a rule won't prevent accidents :)
19:33:41 <tadeboro> We also packaged venv once IIRC, sooo yeah ;)
19:33:43 <odyssey4me> maybe just a CI check with a specific override file for allowances?
19:34:15 <odyssey4me> ie fail the check by default, but we have a list of files which are allowed (with commit msgs for record)
19:34:26 <felixfontein> odyssey4me: sounds like a good idea
19:34:44 <felixfontein> but it also does not protect from packaging errors
19:34:47 <pabelanger> 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 <felixfontein> in the case dmsimard mentioned the large binary was added during collection building, it was not part of the repository
19:35:16 <dmsimard> pabelanger: fwiw galaxy has a hard cap at 20MB so we're "protected" to a certain extent
19:35:26 <odyssey4me> ah, and in most cases this will be a mistake - not an intention
19:36:32 <briantist> 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 <briantist> (or maybe oversight is a better word)
19:37:14 <felixfontein> 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 <dmsimard> 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 <odyssey4me> felixfontein++
19:37:33 <felixfontein> also we have to talk about the size limit first :)
19:37:35 <acozine> 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 <dmsimard> 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 <dmsimard> I mean, from a CI perspective
19:38:27 <felixfontein> 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 <felixfontein> dmsimard: checking at build/release is usually too late somewhat :)
19:39:14 <felixfontein> dmsimard: either it delays the release, or we stop updating a collection (with potential bad side effects)
19:39:30 <dmsimard> I plan on running the build/release process far more often than it does currently
19:39:34 <dmsimard> i.e, not just at release time
19:39:56 <dmsimard> not to cut new releases, but to test continuously that nothing has broken so we're not stranded on release day
19:40:05 <dmsimard> you know, CI :)
19:40:26 <felixfontein> 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 <dmsimard> +1
19:40:45 <felixfontein> does anyone want to start compiling such stats?
19:41:06 * tadeboro hides
19:41:09 <felixfontein> :)
19:41:14 * felixfontein too, too much other things on my plate
19:41:38 <odyssey4me> that seems like the perfect thing for a nightly job to do
19:41:42 <tadeboro> I did download the galaxy once, I do not intend on doing that anytime soon ;)
19:41:51 <odyssey4me> and it looks like dmsimard already plans to do so ;)
19:42:01 <felixfontein> hehe
19:42:27 <dmsimard> I can take it
19:42:37 <pabelanger> 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 <dmsimard> maybe not by next week but I've already done part of that work in that PR
19:42:51 <felixfontein> ok, good :)
19:42:55 <felixfontein> thanks dmsimard!
19:43:09 <odyssey4me> thanks dmsimard - appreciate it...
19:43:14 <felixfontein> pabelanger: does AH have a file size limit?
19:43:22 <pabelanger> unknown
19:43:22 <andersson007_> what will we do with the PR: 1) change MUST to SHOULD 2) close the pr?
19:44:00 <felixfontein> andersson007_: probably it's best to split the editorial changes into another PR so they are not lost :)
19:44:32 <felixfontein> 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 <felixfontein> is abadger1999 around btw?
19:45:12 <acozine> I htink he's on PTO
19:45:12 <felixfontein> (or does someone know he definitely won't be around for this meeting?)
19:45:15 <felixfontein> ah
19:45:24 <tadeboro> 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 <felixfontein> I'd suggest to skip the Python version requirements topic to next week then (when he's back)
19:46:10 <andersson007_> SHOULD works for me
19:46:42 <felixfontein> andersson007_: can you change it to SHOULD and extend it to all files in the collection (and not just tests/integration/)?
19:46:51 <felixfontein> because we don't want large files in other directories as well :)
19:47:06 <andersson007_> felixfontein: sure, right now?
19:47:32 <felixfontein> andersson007_: no, let's discuss it another time
19:47:48 <andersson007_> felixfontein: cool, ok
19:48:50 <felixfontein> 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 <odyssey4me> 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 <odyssey4me> in some cases a collection owner may choose to exclude tests because they are not useful outside of the CI
19:49:17 <felixfontein> odyssey4me: please add a comment/suggestion to that PR :)
19:49:51 <felixfontein> has anyone a preference for one of these topics? otherwise I'd suggest to continue with 2)
19:49:54 <odyssey4me> okey dokey
19:50:14 <pabelanger> 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 <andersson007_> felixfontein: 2 is too controversial imo
19:51:03 <andersson007_> without abadger1999 and gundalow
19:51:35 <andersson007_> we should dedicate a special session for that:)
19:51:45 <samccann> I added 1 (docs for latest collections) to the DaWGs agenda for next week so we don't forget
19:51:50 <felixfontein> ok, fine for me
19:51:58 <felixfontein> samccann: sounds good!
19:52:00 <samccann> would also need abadger's help tho to implement whatever we decide
19:52:29 <acozine> the "docs for latest collections" is basically "devel docs for the community package", right?
19:52:30 <felixfontein> true. we can still discuss what 'community' wants :)
19:52:42 <felixfontein> acozine: not necessarily, but almost :)
19:52:54 <acozine> I mean, we would publish them as `devel`
19:53:00 <felixfontein> 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 <felixfontein> #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 <felixfontein> #info Idea: Separate per-collection docsites for included collections on docs.ansible.com (or somewhere else)?
19:53:10 <felixfontein> #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 <felixfontein> the second idea is what we discussed quickly in the DaWGs meeting
19:54:11 <felixfontein> 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 <felixfontein> tadeboro originally came up with the question (I think based on user feedback)
19:54:39 <samccann> 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 <samccann> so my leaning is toward /ansible/devel/ being ...devel for Ansible the package
19:56:14 <felixfontein> 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 <samccann> 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 <felixfontein> having /ansible/devel/ with prereleases solves most issues, at least for collections which don't do prereleases :)
19:57:12 <samccann> felixfontein - can you explain prereleases?  is this like 2.0.0.1b or something funky like that?
19:57:16 <felixfontein> are there more ideas / wishes / caveats anyone can think of?
19:57:17 <samccann> or 0.0.0.1b
19:57:27 <felixfontein> samccann: yes, like 2.0.0-alpha
19:57:38 <odyssey4me> I like that idea
19:57:50 <acozine> as long as they get onto Galaxy, I think we can pull them based on upload date/time
19:57:52 <felixfontein> 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 <felixfontein> s/customers/users/ :)
19:58:05 <odyssey4me> 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 <samccann> devel isn't stable docs tho
19:58:25 <acozine> if they want stable, they should use the package
19:58:26 <samccann> I see two requests here - one is a 'devel' for Ansible the package
19:58:35 <felixfontein> 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 <samccann> the other is /latest/ for collections
19:58:42 <dmsimard> cybette-clock says we're 58 minutes into the meeting and 5 minutes into the topic
19:59:04 <felixfontein> I like how dmsimard is using the cybette-clock :)
19:59:21 <samccann> heh
19:59:38 <samccann> ok maybe we take a step back.. put on our imaginary use hats
19:59:38 <odyssey4me> devel vs latest, I like that too personally
19:59:43 * dmsimard is cybette-clock by interim
19:59:57 <acozine> I don't think we can do two different types of /latest/ docs
20:00:08 <samccann> I use foo collection. I have Ansible the package. I get the docs on /latest/ today
20:00:31 <felixfontein> acozine: I tihnk we can only have two different kind of /latest/ docs if we have separate docsites for collections
20:00:36 <samccann> 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 <samccann> (community user)
20:00:42 <felixfontein> acozine: but that's something that eats a lot of resources
20:01:07 <acozine> it's also very confusing for search engines
20:01:27 <acozine> we'd have https://docs.ansible.com/ansible/latest/collections/ansible/posix/index.html#plugins-in-ansible-posix
20:01:57 <acozine> 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 <felixfontein> indeed, it is
20:02:10 <felixfontein> bye tadeboro!
20:02:20 <andersson007_> +1
20:02:21 <acozine> tadeboro: have a good evening
20:02:39 <samccann> 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 <samccann> and not includ prereleases
20:03:06 <odyssey4me> another option is a URL parameter - /latest/&devel=true or some such
20:03:15 <odyssey4me> that way the search engin4es don't get hurt
20:03:29 <felixfontein> odyssey4me: that would require some code instead of static pages that are served
20:03:51 <felixfontein> right now the docsite is static pages that are served, which makes it pretty fast
20:04:10 <felixfontein> 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 <odyssey4me> fair enough - if url rewriting is an option, that would do it too... but fair enough
20:04:48 <acozine> 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 <acozine> and `latest` should continue to mean that ^^^
20:05:38 <felixfontein> 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 <felixfontein> for all these, /ansible/latest/ is not really relevant and can provide docs that are out of date
20:06:11 <acozine> we can use `devel` for "most recent releases since the last package release"
20:06:12 <samccann> Tower as official Tower (not awx) - users would I think have paid for Automation Hub and that has the module docs
20:06:21 <dmsimard> even then, different versions of the package will carry different version of the collections
20:06:47 <felixfontein> in any case, it's quite a mess :)
20:07:11 <felixfontein> I'm happy with /ansible/latest/ and /ansible/devel/ where devel has the latest releases
20:07:20 <samccann> +1
20:07:24 <felixfontein> what's the opinion of folks here on whether /devel/ should include prereleases?
20:07:27 <acozine> +1
20:07:46 <acozine> (er, that +1 was not for pre-releases)
20:07:47 <samccann> I'm inclined to vote no on prereleases
20:08:27 <felixfontein> 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 <samccann> 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 <felixfontein> samccann: I'm currently tending that way as well
20:09:04 <felixfontein> are there other opinions on this?
20:09:13 <dericcrago> 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 <dmsimard> what is a pre-release ?
20:09:30 <odyssey4me> :D
20:09:31 <dmsimard> a collection version that is released but isn't yet included in the latest ansible package ?
20:09:32 <felixfontein> dmsimard: like an alpha or beta release of a colleciton, or a release candidate
20:09:44 <felixfontein> look at https://semver.org/ for an exact definition :)
20:10:04 <felixfontein> if a collection version has a pre-release specifier, it is a pre-release
20:10:15 <felixfontein> whatever that means precisely depends on the collection and maybe even collection version
20:10:17 <acozine> 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 <felixfontein> lmodemal: bye!
20:10:32 <acozine> lmodemal: bye!
20:10:55 <odyssey4me> what dmsimard has asked is actually a good one
20:10:57 <felixfontein> acozine: these are not pre-releases
20:11:23 <acozine> that's what I meant, they are full releases
20:11:26 <dmsimard> 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 <odyssey4me> 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 <felixfontein> dmsimard: these are pre-releases for example
20:11:51 <felixfontein> collections can also have beta or alpha or release candidates
20:11:58 <felixfontein> these would be pre-releases as well
20:12:16 <dmsimard> surely including whatever is the latest actual release in the docs is fine ?
20:12:19 <felixfontein> odyssey4me: that are not pre-releases
20:12:24 <dmsimard> rather than needing the logic to handle pre-releases
20:12:25 <acozine> odyssey4me: yes
20:12:27 <felixfontein> odyssey4me: that are releases not included in ansible yet
20:12:48 <felixfontein> we should not start mixing well-defined terminology :)
20:12:54 <odyssey4me> yep, so what is the intent of /devel - to share docs from collections not in ansible yet, or something else?
20:12:56 <samccann> dmsimard - depends on what problem we are solving
20:13:15 <samccann> odessey4me - that's what we are  trying to decide
20:13:25 <felixfontein> odyssey4me: traditionally /devel/ contained the docs from ansible/ansible's devel branch, which is essentially a pre-release
20:13:41 <felixfontein> (of the next ansible-core 'major' release)
20:13:45 <samccann> 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 <felixfontein> but in the collection world, we need to redefine what /devel/ contains next to the ansible-core pre-release
20:14:09 <dmsimard> cybette-clock says we're 74 minutes into the meeting and 20 minutes into the topic
20:14:33 <odyssey4me> 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 <samccann> 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 <felixfontein> samccann: both is fine for me, and both has different pros and cons
20:14:46 <felixfontein> samccann: +1
20:14:57 <odyssey4me> samccann yep, that's what I mean +1
20:15:04 <dmsimard> samccann: +1
20:15:12 <samccann> 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 <acozine> we cam
20:15:28 <acozine> erg
20:15:48 <acozine> we can't publish docs for every single version of every single collection on Galaxy
20:15:59 <odyssey4me> 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 <samccann> phew
20:16:08 <samccann> :-)
20:16:10 <odyssey4me> (or other planets) :)
20:16:14 <felixfontein> :)
20:16:18 <samccann> mars collection!!!
20:16:26 <odyssey4me> I mean, we gotta start thinking about mars, right? :)
20:16:28 <felixfontein> yeah, that's either something galaxy has to do, or something that a collection has to do for itself
20:16:36 <odyssey4me> dammit, you beat me
20:16:42 <felixfontein> creating your own docsite for a collection isn't that hard
20:16:49 <acozine> 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 <samccann> ok so are we ready to vote on ansible /devel/ docs will not include prerelease?
20:17:19 <odyssey4me> acozine yes, that sounds correct
20:17:32 <samccann> acozine: not sure
20:17:52 <samccann> I mean if there is a collection data file for Ansible 4, do we then start publishing that to /devel/?
20:17:55 <felixfontein> VOTE: should /ansible/devel/ use (a) the latest pre-releases of a collection, or (b) just the latest 'stable' releases?
20:18:03 <samccann> b
20:18:07 <acozine> b
20:18:07 <odyssey4me> b
20:18:07 <felixfontein> b
20:18:16 <dmsimard> b
20:18:23 <jillr> b
20:18:32 <dericcrago> b
20:18:58 <felixfontein> /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 <acozine> though we have not yet implemented this, so . . . it will be a few days/weeks before it shows up at all
20:19:44 <felixfontein> true :)
20:19:57 <acozine> just managing expectations a little ;-)
20:20:11 <felixfontein> #agreed /ansible/devel/ should use the latest 'stable' releases (and not pre-releases)
20:20:42 <felixfontein> true :) it needs to be implemented first, but at least now it's clear what exactly should be implemented :)
20:20:48 <acozine> yay!
20:21:48 * acozine must go to prepare for next meeting at the half-hour
20:22:00 <felixfontein> ok, is anyone interested in discussing some more topics, or should we stop 'early' today? :)
20:22:05 <felixfontein> (just 1 h 22 min ;) )
20:22:10 <dmsimard> we're running on almost 90 minutes and the objective was to end before
20:22:16 <dmsimard> we can open up the floor if there are no other topics
20:22:34 <felixfontein> dmsimard: was that an objective? :)
20:22:40 <felixfontein> #topic open floor
20:22:43 <dmsimard> I said it was before the meeting :D
20:22:48 <felixfontein> does anyone has something that should be discussed now?
20:22:58 <felixfontein> (if you have something for the next meetings, just put it on the agenda!)
20:23:03 <felixfontein> dmsimard: ok :D
20:23:20 <acozine> where does the agenda for this meeting live?
20:23:31 <dmsimard> https://github.com/ansible/community/issues/539
20:23:32 <felixfontein> https://github.com/ansible/community/issues/539
20:23:55 <felixfontein> dmsimard: what happened to github-linkbot btw
20:24:06 <acozine> #info add topics to the agenda for this community meeting at https://github.com/ansible/community/issues/539
20:24:14 <acozine> thanks
20:24:21 <dmsimard> felixfontein: it's alive but only expands PRs for now
20:24:26 <felixfontein> ah, right
20:24:29 <dmsimard> I meant to add support for issues too but haven't got around to it
20:24:57 <felixfontein> dmsimard: it did ignore a pull request URL today though
20:24:57 <dmsimard> it's in my flaming pile of TODOs :)
20:24:58 <felixfontein> https://github.com/ansible-collections/overview/pull/157
20:25:10 <dmsimard> ah, I'll figure out why, thanks
20:25:19 <felixfontein> ah, because it was the last one used....
20:25:23 <felixfontein> (before the meeting :) )
20:25:30 <felixfontein> and we had no other PR link during the meeting
20:25:34 <dmsimard> oh, it does keep a memory of the links that were expanded recently
20:25:39 <felixfontein> doesn't happen that often ;)
20:25:44 * samccann needs to drop
20:25:46 <dmsimard> it's not time-limited though
20:25:54 <dmsimard> samccann: o/ thanks for coming
20:25:57 <samccann> #unchair samccann
20:25:57 <zodbot> Current chairs: acozine andersson007_ briantist dericcrago dmsimard felixfontein jillr lmodemal tadeboro
20:26:04 <dmsimard> I think we're good, thanks for coming everyone :)
20:26:17 <dmsimard> odyssey4me: thanks for joining us, appreciate it <3
20:26:40 <acozine> thanks folks!
20:26:41 <dmsimard> #endmeeting