18:00:48 <felixfontein> #startmeeting Ansible Community Meeting
18:00:48 <zodbot> Meeting started Wed Jul  5 18:00:48 2023 UTC.
18:00:48 <zodbot> This meeting is logged and archived in a public location.
18:00:48 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:48 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:48 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/679
18:00:51 <felixfontein> Landrash[m], Leo[m], acozine, andersson007_, anwesha, ascherbaum, baptistemm, bcoca, briantist, cidrblock, cyberpear, cybette, dericcrago, dmsimard, felixfontein, geerlingguy, gotmax, gundalow, gwmngilfen, ikhan_, jillr, jtanner, lmodemal, mariolenz[m], markuman, maxamillion, misc, nitzmahone, ompragash, oranod, resmo, russoz, samccann, thaumos, wbentley15[m], zbr: The Ansible community
18:00:52 <gotmax> .hi
18:00:53 <zodbot> gotmax: Sorry, but user 'gotmax' does not exist
18:00:57 <felixfontein> meeting is starting now!
18:00:59 <felixfontein> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself.
18:01:00 <gotmax> .hello2 gotmax23
18:01:00 <zodbot> gotmax: Sorry, but user 'gotmax' does not exist
18:01:02 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/679 / Topics: https://github.com/ansible-community/community-topics
18:01:05 <felixfontein> #topic Updates
18:01:08 <felixfontein> #chair gotmax
18:01:08 <zodbot> Current chairs: felixfontein gotmax
18:01:08 <gotmax> .hello gotmax23
18:01:10 <briantist> o/
18:01:12 <zodbot> gotmax: gotmax23 'Maxwell G' <maxwell@gtmx.me>
18:01:19 <gotmax> Third time's the charm!
18:01:19 <felixfontein> #chair briantist
18:01:19 <zodbot> Current chairs: briantist felixfontein gotmax
18:01:22 <gotmax> Hi everyone
18:01:35 <briantist> (I'll probably fall off the second half of the meeting)
18:01:43 <oranod> hello
18:01:44 <oranod> o/
18:01:50 <cybette_> o/
18:02:27 <felixfontein> #chair oranod cybette_
18:02:27 <zodbot> Current chairs: briantist cybette_ felixfontein gotmax oranod
18:05:49 <gotmax> I'm going to close  Having only single release in one day #248 as we merged the PR
18:06:19 <felixfontein> ah, I only now saw that it's already merged ;)
18:06:27 <felixfontein> I'm still going through the notifications from today ;)
18:06:37 <felixfontein> thanks everyone! and gotmax, please go ahead and cloes it
18:06:39 <botifico-16655b7> [02community-topics] 07gotmax23 closed issue 03#248: Having only single release in one day - 13https://github.com/ansible-community/community-topics/issues/248
18:09:16 <gotmax> It looks like the leftover topics are community docs (240, 242) and 245 about ansible-core version support
18:10:37 <rakeshboinapally> <felixfontein> "rakesh boinapally: ansible_ssh_a..." <- Okay any idea is it some thing to do with os version earlier execution environments use to have ansible-runner as base image and the execution environments has centos-stream-9
18:10:59 <felixfontein> what do you folks want to discuss? I'm particularly interested in the ansible(-core|-base|) support question obviously ;)
18:11:06 <gotmax> We're in the middle of the Community Meeting, so probably better to save support questions for after :)
18:11:17 <gotmax> You're welcome to stay for the meeting though
18:11:33 <gotmax> felixfontein: we can start with your thing
18:11:39 <felixfontein> rakeshboinapally: or ask in #users:ansible.com, that might be the better room for support questions anyway
18:12:11 <felixfontein> #topic Which/how many versions of ansible(-base|-core) should a (community) collection support?
18:12:16 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/245
18:12:27 * gotmax needs to skim the discussion
18:12:27 <acozine> o/
18:12:41 <felixfontein> I added a concrete proposal for community.general two weeks ago (https://github.com/ansible-community/community-topics/issues/245#issuecomment-1601585504) so we have some basis of discussion
18:12:45 <felixfontein> #chair acozine
18:12:45 <zodbot> Current chairs: acozine briantist cybette_ felixfontein gotmax oranod
18:12:45 <mariolenz[m]> o/
18:12:49 <felixfontein> #chair mariolenz[m]
18:12:49 <zodbot> Current chairs: acozine briantist cybette_ felixfontein gotmax mariolenz[m] oranod
18:13:41 <felixfontein> it was published in The Bullhorn 106 (https://mailchi.mp/redhat/the-bullhorn-106, look for 'PROPOSALS - DISCUSS AND VOTE!')
18:13:49 <felixfontein> so far, there was no reaction except a single up-vote :)
18:14:09 <briantist> I am a little confused about the core version support issue, since collections already can choose their own adventure there
18:14:16 <briantist> which is mentioned in the issue
18:14:46 <briantist> so I guess I'm wondering what we expect the outcome of this discussion to be
18:14:56 <felixfontein> briantist: they can, but the more versions you support the more you are limited by missing features and CI resource requirements
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:17 <felixfontein> so we have to cut off support for old versions at some point - and the question is when that should happen
18:15:38 <briantist> indeed, which are some of the aspects that go into making that decision, but to me it feels that needs to happen at the individual collection level
18:15:41 <felixfontein> I don't want to that community.general 20.0.0 supports ansible-core 2.11, 2.12, 2.13, 2.14, 2.15, 2.16, 2.17, 2.18, 2.19, 2.20, 2.21, ... ;)
18:16:09 <briantist> so is the issue specifically about `c.g`?
18:16:14 <acozine> so the proposal is to support a limited number of releases (current, current-1)?
18:16:23 <felixfontein> briantist: the idea is to give some guidelines that collections can follow
18:17:01 <felixfontein> c.g is an example as there the question is more pressing (used by many, and CI matrix is large), and so that we have something concrete to talk about
18:17:14 <felixfontein> so far everyone can agree on "support should be eventually dropped", but that's about it
18:17:48 <felixfontein> acozine: the concrete proposal is to support for c.g x.y.z all ansible-core versions that were not EOL when x.0.0 was released (resp. a few weeks before that)
18:18:20 <acozine> that seems reasonable ot me
18:18:31 <gotmax> I think we should support the upstream supported ansible-core releases and perhaps provide a one-release grace period after EOL
18:18:41 <acozine> if folks need older ansible-core versions for some reason, they can use older c.g. versions with them
18:18:53 <gotmax> Right
18:19:21 <felixfontein> I'm maintaining several collections which never had a 2.x.y release so far, and they still support everything from Ansible 2.9 on - which is getting more and more; I have no idea when is a good time to drop some of these versions, as there's no other reason to make a new major release
18:19:31 <jtanner> hi
18:20:08 <felixfontein> gotmax: since the oldest ansible-core version that isn't EOL a few weeks before c.g x.0.0 is EOL a few weeks after x.0.0 is out, I think the proposal already includes that :)
18:20:14 <felixfontein> #chair jtanner
18:20:14 <zodbot> Current chairs: acozine briantist cybette_ felixfontein gotmax jtanner mariolenz[m] oranod
18:20:30 <gotmax> Cool
18:20:39 <felixfontein> the problem with using older c.g versions is that a) newer features are missing, b) eventually there are also no more bugfixes
18:21:26 <felixfontein> gotmax: the reason I wrote "a couple of weeks before" is to make sure that that version is still supported, even if for some reason it's already declared EOL a few days before the c.g x.0.0 release
18:21:57 <gotmax> Right
18:22:13 <gotmax> What do you see as the next steps?
18:22:30 <felixfontein> try to publicize the proposal more, wait some more time for feedback
18:22:39 <briantist> sorry, my computer crashed just as I was typing a reply
18:22:52 <gotmax> I feel that :(
18:23:28 <briantist> I'm ok with providing guidelines,  but generally feel that the decision is up to the collection maintainer(s). If you (as a maintainer) don't feel empowered to make that decision, then that's a problem we really need to address.
18:23:38 <felixfontein> I would probably wait at least a month (probably more) before starting a vote on this concrete proposal (since SC also kind of governs c.g), so that everyone has time to react
18:23:58 <felixfontein> briantist: the decision should definitely be up to collection maintainers!
18:24:51 <briantist> > I have no idea when is a good time to drop some of these versions, as there's no other reason to make a new major release
18:24:51 <briantist> to me, since we've concretely said that a core version can only be dropped in a major release, doing a major release specifically to drop a core version is completely valid
18:25:31 <gotmax> The only thing about major releases is the implications for the ansible package.
18:25:36 <felixfontein> it is valid, but it shouldn't be done too often - doing a major release every 6 months like c.g just to drop support for EOL ansible-core versions seems rather extreme, if there is nothing else that changes
18:25:46 <briantist> I also think it's valid if you want to put those kind of changes up for a vote, especially for something like `c.g`, but ultimately that vote can only be a recommendation to the people who actually maintain it
18:26:27 <gotmax> If ansible 8 contains ansible-core 2.15 and you create a new major release now to drop support for 2.11, that collection won't see updates for months even if the change isn't breaking in the context of the ansible package
18:26:44 <gotmax> Well, not "the only thing", but a complicating factor...
18:26:56 <felixfontein> I guess a general guideline would be to do a major release regularly - say at least every two years? - to clean up, but I have no idea whether the "two years" I put here is considered good, too litle, or too much by others
18:27:31 <felixfontein> gotmax: I usually try to align my collection releases with Ansible releases, in particular major releases ;)
18:27:43 <gotmax> Right, that's a good way to go about it
18:27:44 <briantist> I don't think it's very extreme tbh. If there's no other changes at all, you don't need to do a new major version unless CI starts failing and you need to drop support to fix it. For a collection like `c.g` with multiple supported stable versions, it's also ok to drop older version support without doing a new release right? like if current major is `5.x` and you want to stop supporting `1.x` I think it's fine to just...
18:27:44 <briantist> sort of stop?
18:28:02 <gotmax> but it does add a constraint for maintainers
18:28:39 <felixfontein> briantist: I don't mean dropping support for older stable branches of the collection, but dropping support for older ansible-core versions
18:29:23 <briantist> let's also remember that many python projects in general are getting much more aggressive about dropping unsupported python versions, which is probably a good thing, so there's kind of a norm for it...?
18:29:39 <briantist> yeah I only mentioned that because in theory you can never drop a supported core version from a stable branch right?
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:04 <felixfontein> briantist: the way I interpret semantic versioning, you can't. I'm not sure everyone agrees with me on that, though :)
18:30:27 <gotmax> I'm against dropping support for versions just for the sake of it, but when we have limited maintainer and CI resources...
18:31:07 <gotmax> or when supporting older versions adds maintenance burden or prevents adoption of new features
18:31:32 <gotmax> FWIW, I agree that dropping support for ansible-core versions constitutes a breaking change
18:31:44 <briantist> I agree gotmax , I tend to drop only when it becomes a problem, though sometimes doing that leads to very acute problems that can't easily be announced, so it's a balance
18:32:38 <briantist> but I am also hitting the wall of not enough time in the day, so, it really is hard to keep supporting versions that even redhat won't support :)
18:33:05 <gotmax> Red Hat still supports 2.9
18:33:11 <felixfontein> community.general has the advantage that it has a new major release every six months anyway, so dropping support for older ansible-core versions is relatively easy for it
18:33:18 <gotmax> Right
18:34:07 <felixfontein> what do you think about the concrete proposal for c.g? does it sound reasonable? would you support more ansible-core versions? (or even less?)
18:34:59 <gotmax> It sounds very reasonable to me
18:35:39 * gotmax is trying to write a script to see which core versions each collection in ansible supports but is bad at multitasking
18:35:47 <gotmax> I'll post results later
18:36:10 * acozine is also bad at multitasking, and is building EEs, or trying to
18:36:23 <mariolenz[m]> Since ansible-core releases a new "major" release (they don't really follow semenatic versioning, do they?) I don't think a new major release of a collection every two years is too much. Actually, I'm planning to do a new major release of community.vmware once a year and drop support for version current - 2. I've released version 3 last year and dropped support for version 1. And I'm planning to release version 4 in a couple of
18:36:23 <mariolenz[m]> months and drop support for version 2. I don't think there are any guidelines or even requirements against this, or are there?
18:37:02 <mariolenz[m]> * Since ansible-core releases a new "major" release (they don't really follow semenatic versioning, do they?) every 6 months I don't think a new major release of a collection every two years is n'ttoo much. Actually, I'm planning to do a new major release of community.vmware once a year and drop support for version current - 2. I've released version 3 last year and dropped support for version 1. And I'm planning to release
18:37:02 <mariolenz[m]> version 4 in a couple of months and drop support for version 2. I don't think there are any guidelines or even requirements against this, or are there?
18:37:50 <felixfontein> mariolenz[m]: there are none - you should only support the latest release train, what you do with previous release trains is up to you... (if you do larger breaking changes users might be happy if you support the older ones for some time, but that's up to you - nobody forces you to do it for them)
18:38:19 <felixfontein> mariolenz[m]: which versions of ansible-core do you plan to support for every new major release? if you already have an idea for that :)
18:44:36 <felixfontein> is there another topic someone wants to discuss? or should we switch to Open Floor if there is no more input for the current topic?
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:16 <mariolenz[m]> I thought about the latest ansible-core minus 1. IIRC I've released community.vmware 3 when ansible-core 2.14 was the latest current release and it supports 2.13+. My plan is to release community.vmware 4 when ansible-core 2.16 already has been released and support 2.15+ there. I thought that this might be a good idea, but I'm open to arguments against this.
18:46:13 <felixfontein> I don't have an argument against it; I'm more curious if you got any (negative) feedback from users of the collection about that :)
18:46:24 <gotmax> FTR, about 75 % of the collections in ansible still claim to support 2.9
18:47:09 <felixfontein> (I wonder how many of them actually do :) )
18:47:34 <gotmax> containers.podman and openstack.cloud have '>=2.8'...
18:47:56 <gotmax> Anyways, I guess we can move to Open Floor
18:49:33 <felixfontein> #topic Open Floor
18:49:54 <felixfontein> I think 2.8 had first collection support, but I don't know how much actually works (I never tried it)
18:50:08 <gotmax> Yeah
18:50:32 <mariolenz[m]> Open floor? I've opened a new vote: https://github.com/ansible-community/community-topics/discussions/249
18:50:45 <acozine> in 2.8 I think collections were experimental
18:50:59 <gotmax> felixfontein and I now have commit on ansible-documentation. I guess the next steps are to add the rest of the SC.
18:51:02 <acozine> mariolenz: thanks for doing all this tidying up!
18:51:06 <gotmax> #link https://github.com/ansible-community/community-topics/issues/243#issuecomment-1617788767
18:51:17 <briantist> gotmax: I think for a while, it was easy to forget to update `meta/runtime.yml` so even with dropping support, some might still "claim" it's supported in there
18:51:29 <briantist> if that's how you were looking for that support
18:51:31 <felixfontein> #info Please consider the community vote on removing netapp.azure from Ansible 10: https://github.com/ansible-community/community-topics/discussions/249
18:51:37 <gotmax> Yes, that was
18:52:36 <felixfontein> 2.8 and 2.9 didn't look at meta/runtime.yml anyway
18:52:47 <mariolenz[m]> I'm afraid there will be some more votes about [unmaintained collections](https://github.com/ansible-community/community-topics/issues/128#issuecomment-1507223524) in the future :-/
18:53:50 <oranod> gotmax: I'd be happy to add the rest of the SC if you want
18:53:51 <gotmax> Re. https://github.com/ansible-community/antsibull-docs/pull/177, I'm not sure I'm familiar enough with that code to properly review it, but I can try and take a look later
18:54:30 <felixfontein> gotmax: thanks, that would be great :)
18:54:56 <felixfontein> I'm also interested in feedback on the output (as demonstrated in https://github.com/ansible-collections/community.vmware/pull/1788)
18:55:23 <gotmax> felixfontein, do you want to provide a bit of context
18:55:30 <felixfontein> while the new output format is declared as experimental, it would be great to not having to make big changes after releasing a first version of it :)
18:55:32 * gotmax worries that no one else knows what we're talking about :)
18:55:55 <felixfontein> the antsibull-docs PR allows to create RST files for docs/ in collections, similar to what collection_prep does right now
18:56:37 <felixfontein> since collection_prep doesn't seem to be actively maintained anymore this is useful for collections that used collection_prep for that purpose but now want to use semantic markup
18:57:03 <gotmax> And the idea is that they're in a simplified format that display properly in Github, right?
18:57:06 <mariolenz[m]> I think this would be a great feature since collection_prep looks somewhat unmaintained. Didn't find the time to have a closer look at it, though :-(
18:57:06 <felixfontein> (semantic markup PR for collection_prep: https://github.com/ansible-network/collection_prep/pull/88)
18:57:33 <felixfontein> gotmax: yes, I think so - though I never really understood what these .rst files were for in docs/, that they are for display on GitHub is my personal guess
18:57:55 <felixfontein> if someone knows what the main usecase for these .rst files in docs/ is, please enlighten me :)
18:58:28 <felixfontein> I hope it's not just "we always did it like that" and/or "nobody remembers why we started doing it" :)
18:58:29 <gotmax> I know that some collections use RTD or Github actions or whatever to generate personal docsites for their collections, but I guess this provides a lighter weight approach
18:59:38 <felixfontein> do you know of any collection that uses collection_prep for RTD / GHA based docs publishing?
19:00:36 <felixfontein> there's also https://github.com/xlab-steampunk/ansible-doc-extractor which creates RST files; that one has semantic markup support in the development branch (merged today), though I don't know when there will be a new release
19:00:38 <briantist> gotmax: the Windows collections used to generate the RSTs in the `docs/` folder as well, but it was a pain since it required manual steps to do that during releases. In those, it has been replaced completely with github-docs-build
19:01:05 <briantist> the AWS collections use the GHA-based stuff too, though I don't remember if they also generated and committed RST files in `docs/`
19:01:29 <gotmax> Some collections use antsibull-docs to generate their own docsites. Generating rst files with collection_prep or similar and just storing them in the repo is an alternative approach.
19:01:33 <felixfontein> for anyone who doesn't know, github-docs-build is using antsibull-docs (https://github.com/ansible-community/github-docs-build)
19:01:55 <felixfontein> the AWS collections did have .rst files in docs/ as well
19:01:58 <briantist> thanks felixfontein  :)
19:02:35 <felixfontein> briantist: you removed the ones from community.aws in d1e05820c9162ac56002bf0efff73ad19a2d0e22 on Sept 8 2022 ;)
19:03:22 <briantist> heh yeah.. I remember removing them from the windows collections, and I remember putting up PRs for the AWS collections, but I couldn't quite remember if the individual docs existed there too 🙃you're quick with the history!
19:04:20 * gotmax notes the time
19:04:21 <felixfontein> `git log --stat docs/` - scroll one page down and you see a lot of .rst files deleted ;)
19:04:25 <felixfontein> yeah, right
19:04:31 <felixfontein> thanks everyone, it's time to close the meeting!
19:04:35 <felixfontein> #endmeeting