18:00:04 <gundalow> #startmeeting Ansible Community Meeting
18:00:04 <zodbot> Meeting started Wed Jul 22 18:00:04 2020 UTC.
18:00:04 <zodbot> This meeting is logged and archived in a public location.
18:00:04 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:04 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:27 <gundalow> #chair felixfontein abadger1999 rbergeron gregdek
18:00:27 <zodbot> Current chairs: abadger1999 felixfontein gregdek gundalow rbergeron
18:00:43 <cyberpear> .hello2
18:00:44 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
18:00:49 <gundalow> jimi|ansible: nitzmahone you around?
18:00:50 <felixfontein> yay!
18:00:54 <felixfontein> thanks for starting the meeting, gundalow!
18:01:02 <nitzmahone> ya
18:01:07 * cyberpear sorry to have missed the past couple
18:01:14 <gundalow> #chair cyberpear nitzmahone
18:01:14 <zodbot> Current chairs: abadger1999 cyberpear felixfontein gregdek gundalow nitzmahone rbergeron
18:01:26 <samccann> helloooo
18:01:37 * gwmngilfen needs to rethink having "Greg" in his highlight words ...
18:01:38 <abadger1999> Óla
18:01:46 * nitzmahone lurks, working on a PR- ping me if needed
18:02:09 <gundalow> gwmngilfen: :)
18:02:14 <gundalow> #chair samccann
18:02:14 <zodbot> Current chairs: abadger1999 cyberpear felixfontein gregdek gundalow nitzmahone rbergeron samccann
18:02:20 <gundalow> #info Agenda https://github.com/ansible/community/issues/539
18:02:45 <felixfontein> can I suggest to start with https://github.com/ansible/community/issues/539#issuecomment-662598339 ?
18:02:49 <gundalow> Topics wise I see
18:02:49 <gundalow> 1) when exactly to release 1.0.0 of c.g and c.n? (Suggestion: July 31st) from felixfontein
18:03:00 <gundalow> hehe
18:03:12 <felixfontein> :)
18:03:14 <gundalow> #topic Release 1.0.0 of community.general and community.network
18:03:35 <felixfontein> next topics would be https://github.com/ansible/community/issues/539#issuecomment-656693139 and https://github.com/ansible/community/issues/539#issuecomment-656098926 (in whichever order)
18:03:55 <felixfontein> when we announced that 1.0.0 of c.g and c.n will be released by the end of july, we didn't specify a specific date
18:04:00 <gundalow> I'm not aware of any other content that needs removing from c.g or c.n
18:04:14 <felixfontein> me neither
18:04:34 <felixfontein> to be precise, we said "1.0.0 (last week of July 2020)" (https://github.com/ansible-collections/community.general/issues/582)
18:04:42 <samccann> we should have 2.10 published with the docs pipeline work by tomorrow so you can verify everything looks good up there
18:05:01 <gundalow> samccann: that's good to know thanks
18:05:38 <gundalow> Do we want to check the docs are good before we branch?
18:06:17 <samccann> you can poke aorund on test if you want to verify right now - http://docs.testing.ansible.com/ansible/2.10/collections/index.html
18:07:01 <felixfontein> with https://github.com/ansible-community/antsibull/pull/146 they'll be more correct ;)
18:07:23 <felixfontein> I think we had some docs changes between the last release and the current `main` state in c.g and c.n
18:07:40 <felixfontein> but I think we can also fix broken docs in 1.1.0 if needed
18:08:29 <samccann> just curious - could docs fixed go into say a 1.0.1 type release?
18:08:30 <gundalow> samccann: abadger1999 Is it a know issue that modules are listed in c.g http://docs.testing.ansible.com/ansible/2.10/collections/community/general/index.html#plugins-in-community-general
18:08:51 <felixfontein> samccann: that could be done, but only if we didn't merged a new feature in the stable-1 branch
18:09:29 <felixfontein> samccann: or we could create a special stable-1.1 branch (branched from shortly after the stable-1 branch point) and cherry-pick the doc fixes there as well, if needed
18:09:30 <abadger1999> @gundalow You mean, modules are not listed there?  I had not noticed that :-(
18:09:45 <gundalow> abadger1999: interestingly there are there for c.network
18:10:07 <felixfontein> interesting, I saw modules listed for other collections as well
18:10:08 <samccann> felixfontein: not looking for special consideration, just wondering if docs changes only qualify for a 1.0.x release from a semver perspective
18:10:09 <abadger1999> yeah and community.crypto...
18:10:35 <felixfontein> samccann: I'd say they do, at least if they are mainly docs "bugfixes" :)
18:11:14 <abadger1999> gundalow: I'm opening a bug on antsibull now.  That seems like a high priority for me to fix.
18:11:34 <gundalow> abadger1999: thanks
18:11:38 <samccann> we'll hold off on publishing 2.10 until that's fixed. Thanks for catching it!
18:11:52 <felixfontein> would be interesting to know why that happens, if it is caused by a bug in ansible, a bug in antsibull, a bug in the collection data, or multiple of these
18:12:21 <felixfontein> hmm, it **could** be related that listing only considers modules in plugins/modules/ without subdirectories, and that it ignores meta/runtime.yml
18:12:34 <gundalow> felixfontein: that's what I wondered, though c.network had modules
18:12:45 <gundalow> has module docs
18:13:01 <felixfontein> the current test release of c.g only has meta/runtime.yml redirects, while the current c.n release, and c.g and c.n 1.0.0 will have symlinks
18:13:17 <felixfontein> gundalow: the current c.n release has symlinks, the current c.g release does not
18:13:26 <gundalow> felixfontein: ah, that could be it
18:13:28 <gundalow> abadger1999: ^
18:13:57 <felixfontein> I think we did this special c.g release to find potential bugs which are caused when symlinks are not used, but meta/runtime.yml is - and I guess this is the first we found ;)
18:14:38 <felixfontein> though I'm not sure whether it counts as a bug, since its a known limitation and probably won't get fixed for 2.10 if I remember this correctly
18:15:39 <abadger1999> felixfontein: yeah, I bet that's it.
18:15:47 <gundalow> #info c.general and #c.network need have correctly generated plugin docs before we release 1.0.0
18:16:04 <abadger1999> Because we're still using the ansible-doc backend and I bet the current ansible-doc doesn't handle runtime.yml yet.
18:16:20 <samccann> I just posted a request to some other teams to check their collections. I dont know if anyone else has done this or not
18:16:22 <gundalow> abadger1999: ah, interesting. Is there an issue/PR for that?
18:16:37 <felixfontein> it doesn't IIRC. bcoca probably has a (WIP?) PR for it somewhere
18:16:44 <felixfontein> I wonder where there's an issue for this
18:16:50 <felixfontein> (in ansible/ansible)
18:17:00 <abadger1999> gundalow: there is a PR for ansible-doc to gain that functionality and there's an issue for antsibull to gain a new backend that can do that on its own.
18:17:07 <samccann> so is this an antsibull-docs item that we can fix, or is the 'fix' to get those simlinks there?
18:17:19 <abadger1999> I have not tested the ansible-doc PR, though, so I don't know how complete it is.
18:17:29 <abadger1999> samccann: I think both.
18:17:31 <samccann> (for this ansible release coming real soon now)
18:17:41 <abadger1999> We have a problem.... there's two solutions for it.
18:17:42 <felixfontein> samccann: I guess it's harder to fix on the antsibull-docs side, but the 1.0.0 release of c.g should also fix it
18:17:56 <samccann> ok will it be fixed for the ansible release or a post-release fix? If anyone else hits this snag, I'd like to know what to tell them
18:18:01 <abadger1999> <nod> I agree with felixfontein's analysis.
18:18:35 <samccann> ok so the problem is the collectoin depends on runtime.yml and needs to have simlinks for now as thats what will work for 2.10 (ansible) yes?
18:18:40 <felixfontein> samccann: looks like a post-release fix for ansible itself
18:19:14 <felixfontein> from a very quick glance, I think this is the ansible/ansible PR: https://github.com/ansible/ansible/pull/70207
18:23:19 <felixfontein> ok, back to the original question: when should we release 1.0.0 of c.g and c.n? :)
18:23:23 <abadger1999> https://github.com/ansible-community/antsibull/issues/147
18:23:47 <abadger1999> (Issue for fixing antsibull-docs)
18:23:48 <gundalow> felixfontein: Do you know of any of https://github.com/ansible-collections/community.general/pulls which should be merged first, I'm not aware of any
18:23:53 <gundalow> abadger1999++
18:24:24 <felixfontein> gundalow: there's nothing I'm aware of that's absolutely essential. would be nice of course to get some more bugfixes in, and maybe some more new content
18:24:55 <felixfontein> abadger1999: for properly creating redirect stubs, we need to parse meta/runtime.yml anyway
18:25:38 <gundalow> bugfixes without needs_revision: https://github.com/ansible-collections/community.general/pulls?q=is%3Apr+is%3Aopen+label%3Abug+-label%3Aneeds_revision
18:26:11 * acozine shows up late
18:26:33 <felixfontein> I definitely think it's good to announce a release date at least a few days in advance, so PR authors (if they notice the announcement) know that they should do requested changes now if they want the changes to be included
18:27:16 <abadger1999> felixfontein: yep.
18:27:28 <cyberpear> agreed on the announcement w/ couple days "head's up"
18:27:33 <samccann> +1
18:27:40 <acozine> +1
18:28:37 <gundalow> #chair acozine
18:28:37 <zodbot> Current chairs: abadger1999 acozine cyberpear felixfontein gregdek gundalow nitzmahone rbergeron samccann
18:28:41 <gundalow> welcome
18:29:34 <felixfontein> I mainly suggested July 31st because I definitely will have time on that day to do something for the release
18:29:36 <gundalow> how about 1.0.0 on Thursday 30th (as Fridays are bad)
18:29:55 <gundalow> felixfontein: oh, if you have time then, that would be ace
18:29:58 <gundalow> +1
18:30:12 <gundalow> POLL c.g and c.n 1.0.0 on Fri 31st July
18:30:14 <gundalow> +1
18:30:16 <felixfontein> +1
18:30:21 <abadger1999> +1
18:30:24 <samccann> +1
18:31:17 <felixfontein> I'll try to write complete instructions for a major release today or tomorrow
18:31:26 <acozine> +1
18:32:06 <samccann> so if c.g won't have the docs fix until next Friday, should we publish 2.10 docs anyway (so we have 'alpha' docs for community users to go with 2.10 alpha?)
18:32:19 <samccann> or no because c.g is so big?
18:32:40 <felixfontein> will the 2.10 docs be visible for people who don't know they exist?
18:32:46 <felixfontein> (i.e. will they show up in the version selector?)
18:32:58 <samccann> hmm. there weren't going to be yet, no
18:33:01 <acozine> not by July 31st, no
18:33:29 <felixfontein> if they are not "public" in that sense, I think it's ok if they are not complete
18:33:31 <samccann> we typically change the version selector very close to the actual release
18:34:35 <felixfontein> abadger1999: when do you plan to release the next ansible alpha version?
18:34:40 <abadger1999> I second felixfontein's opinion.
18:35:09 <gundalow> can we talk about next alpha as the next topic?
18:35:19 <gundalow> as I have some other things under that topic
18:35:26 <abadger1999> felixfontein: Heh, plan == every Thursday but I have been missing that deadline (usually one day late)
18:35:55 <abadger1999> <nod>
18:36:08 <felixfontein> gundalow: sounds good to me!
18:36:26 <felixfontein> #agreed c.g and c.n 1.0.0 will be released on Friday, July 31st
18:36:44 <felixfontein> #action felixfontein write instructions for how to do major release (and maybe also minor / patch releases) for c.g and c.n
18:36:54 <felixfontein> #action felixfontein announce 1.0.0 date in repo issues
18:37:06 <gundalow> samccann: Could you possibly mention collection docs, 1) what to check for 2) where to report issues 3) that we know c.general is broken 4) anything else on https://github.com/ansible-collections/overview/issues/45 (changes impacting contributors)
18:37:26 <felixfontein> abadger1999: if you'd release one on July 31st, we'd have an alpha which has 1.0.0 of c.g and c.n
18:38:03 <samccann> gundalow: yes but I'd like to point them to the 2.10 alpha docs vs the test site if you are okay w/ waiting a day?
18:38:10 <abadger1999> felixfontein: <nod>  I just need to remember not to release on Thursday next week.
18:38:24 <samccann> acozine and I meet right after this to decide on publish/no publish today
18:38:26 <gundalow> samccann: fine with me
18:38:37 * baptistemm send a ICS for the whole day "do nothing"
18:38:49 <samccann> #action samcann mention collection docs, 1) what to check for 2) where to report issues 3) that we know c.general is broken 4) anything else on https://github.com/ansible-collections/overview/issues/45 (changes impacting contributors)
18:38:51 <gundalow> baptistemm: could you invite me to that meeting
18:38:56 <felixfontein> #action abadger do not release a new alpha on Thursday July 30th, but wait until Friday July 31st
18:39:01 <gundalow> hehe
18:39:19 <abadger1999> hee hee
18:39:21 <gundalow> Excellent, anything else on this topic?
18:39:47 <felixfontein> I think we can go to the next topic
18:39:52 <felixfontein> (at least from my side :) )
18:39:53 <samccann> #action samccann acozine republish 2.10 on Fri July 31 (after c.g release an ansible alpha release)
18:41:14 <felixfontein> gundalow: you mentioned you want to discuss the alpha schedule for 2.10 (or something more general) next?
18:41:47 <felixfontein> abadger1999: do you have something pressing that should be discussed today (that's not covered by gundalow's topic)
18:42:10 <gundalow> I have two things 1) we are hiring 2) https://gist.github.com/relrod/1d5ca563707741e616be9da2e22f59bf
18:42:14 <gundalow> #chair
18:42:14 <zodbot> Current chairs: abadger1999 acozine cyberpear felixfontein gregdek gundalow nitzmahone rbergeron samccann
18:42:20 <gundalow> anyone have any other topics
18:42:45 <abadger1999> I'll note that I'm assembling a few PRs that change the command line interface of anstibull-build
18:42:59 <abadger1999> And also antsibull-docs.
18:43:06 <felixfontein> abadger1999: can you #info that?
18:43:09 <abadger1999> That shouldn't affect too many people but there will be a few.
18:43:52 <abadger1999> #info antsibull-docs CLI change:  Rename --ansible-base-cache to --ansible-base-source
18:44:16 <abadger1999> #info antsibull-build CLI change: Remove the redundant build- prefix from antsibull-build subcommands
18:44:59 <abadger1999> #info both antsibull-docs and antsibull-build file format change: Renaming "acd_" fields to "ansible_" and renaming default filenames in the same way.
18:45:54 <felixfontein> gundalow: looks like netbox_interface and vmware_rest are still open? and are there other entries where we had no reaction yet?
18:45:55 <abadger1999> #info the changes that affect antsibull-docs will operate with backwards compatibility for at least a few weeks [probably until after 2.10.0 is released]
18:46:44 <gundalow> #topic Open Floor
18:47:01 <felixfontein> gundalow: we still have some more topics
18:47:08 <gundalow> #undo
18:47:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fb1b8b70cd0>
18:47:11 <gundalow> sorry
18:47:21 <felixfontein> np :)
18:47:36 <felixfontein> was there anything else you had about https://gist.github.com/relrod/1d5ca563707741e616be9da2e22f59bf ?
18:48:03 <gundalow> felixfontein: nothing apart from what I've put on it
18:48:21 <felixfontein> gundalow: ok, so it's mostly for information then
18:48:36 <gundalow> yup, the others I can't find
18:49:09 <felixfontein> btw, abadger1999 listed some details on the (tentative) schedule for 2.10, and there were a few things we had questions about I think
18:50:14 <felixfontein> f.ex. there was an entry "2020-08-18 (Tuesday): Ansible 2.10 Beta freeze" - do you know what that is supposed to mean? freeze on the number of collections in ansible? or what exactly is frozen?
18:50:52 <felixfontein> then there's another freeze, "2020-09-08 (Tuesday): Ansible 2.10 Final freeze"
18:51:20 <felixfontein> which of these freezes is for determining which major version of a collection will be used in 2.10?
18:52:05 <abadger1999> I was thinking beta freeze but I need rbergeron to confirm (she's in meetings today)
18:52:07 <felixfontein> and will new minor releases of collections be allowed between RC1 and GA of 2.10.0? (or patch releases?)
18:52:19 <abadger1999> can we list out questions that I should make sure get answered/clarified?
18:52:39 <abadger1999> #action abadger to get clarification from rbergeron about some of th edates and milestones
18:52:49 <felixfontein> we need to announce things to collection owners, soon, and I think that's a pretty important deadline, so it would be good to know when it will be :)
18:53:35 <abadger1999> #info Which freeze date determines the major version of collections that will go into Ansible-2.10 (abadger1999 suggests beta freeze date)
18:53:55 <abadger1999> #undo
18:53:55 <zodbot> Removing item from minutes: INFO by abadger1999 at 18:53:35 : Which freeze date determines the major version of collections that will go into Ansible-2.10 (abadger1999 suggests beta freeze date)
18:54:02 <abadger1999> #info Question1: Which freeze date determines the major version of collections that will go into Ansible-2.10 (abadger1999 suggests beta freeze date)?
18:55:25 <felixfontein> we still need to get https://github.com/ansible-collections/overview/pull/90 completed
18:55:30 <abadger1999> #info Question2: Will either new minor releases or patch releases of collections be allowed between RC1 and GA of 2.10.0 (abadger1999 suggests no, but might need ask to adjust the rc->GA dates in that case)?
18:55:32 <felixfontein> (before we can start posting this into all collection repos)
18:57:09 <abadger1999> Any other schedule questions I should make sure robyn and I discuss?
18:57:52 <gundalow> Just define the dates, and be clear what's meant by the dates (ie what exactly does freeze mean)
18:59:03 <felixfontein> I think these are the main questions. having a public place where these dates can be found (and updated) would also be nice :)
18:59:46 <samccann> there's the roadmap in docs that should have this detail once it's settled.
18:59:57 <abadger1999> @gundalow <nod>  Any other things you need to know about what freeze means besides above?  I'll nail down what I can think of but I'll probably leave something out.
19:00:13 <felixfontein> samccann: I think the roadmap is for ansible-base only right now
19:00:37 <gundalow> `ansible` roadmap should link to ansible-base roadmap and vv
19:00:44 <samccann> then we should add an ansible section to it and rename the existing section as ansible-base
19:00:49 <felixfontein> samccann: a similar solution as for the porting guide might be needed here :)
19:00:59 <samccann> gundalow ?? not sure what you are saying
19:01:49 <gundalow> https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_10.rst should link to the new ansible (add) roadmap
19:02:06 <abadger1999> Sounds like the two suggestions so far are (1) Separate sections on the existing page (2) move current roadmap to an ansible-base-roadmap page and have the new roadmap link to that  ?
19:02:28 <acozine> so we should add a separate link for `ROADMAP_base_2_10.rst` to https://docs.ansible.com/ansible/latest/roadmap/index.html?
19:03:06 <gundalow> I'd assumed they'd be separate places (repos)
19:03:16 <felixfontein> should ROADMAP_2_10.rst be renamed to ROADMAP_2_10_base.rst or ROADMAP_base_2_10.rst?
19:03:23 <samccann> yeah I like separate rst pages
19:03:35 <samccann> easier to move once we find a way to split base docs off on their own
19:03:59 <felixfontein> I guess the big docsite split will come only after ansible 2.10.0 has been released
19:04:09 <acozine> gundalow: that's one of those "how are we going to structure the docs longer-term?" quesions
19:04:11 <felixfontein> (since it needs to be planned first)
19:04:21 <acozine> felixfontein: agreed
19:04:25 <gundalow> at the moment I think I'm -1 to the Ansible roadmap living in gh/ansible/ansible
19:04:47 <felixfontein> gundalow: at the moment, there is no other place where it could live when it should appear on docs.ansible.com
19:04:54 <acozine> we have no other way to publish it to docs.ansible.com . . . should we publish it somewhere else?
19:04:56 <gundalow> does it have to live there?
19:05:22 <acozine> no, it could live as a markdown file on the collections general repo, perhaps
19:05:29 <samccann> the average user expects ansible roadmap in ansible docs, regardless of what GH source is feeding into it
19:05:34 <samccann> disagree
19:05:35 <acozine> but it will get more traffic on docs.ansible.com
19:05:53 <samccann> our docs are predomenently ansible docs, not ansible-base
19:06:04 <samccann> (user docs I should say)
19:06:19 <acozine> gundalow: if you want to make a deeper distinction on the docsite, we can look at ways to do that in future
19:06:45 <acozine> for right now I would prefer to have everything centralized
19:06:59 <acozine> but that's one vote among many
19:07:02 <gundalow> 1) How about a file in https://github.com/ansible-collections/overview/
19:07:03 <gundalow> 2) Link from https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_10.html
19:07:03 <gundalow> 3) Linked from https://docs.ansible.com/ansible/devel/roadmap/index.html
19:07:33 <gundalow> (and the new file links back to `(2)`)
19:07:36 <felixfontein> gundalow: a related question is where the 2.10 porting guide should go
19:07:40 <acozine> we could do that . . .what would the advantage be?
19:08:24 <gundalow> Just seems strange that package A's roadmap is package B's repo + docsite
19:08:58 <gundalow> If everybody else is happy, then ignore me
19:09:11 <gundalow> though I like the idea that the ROADMAPs be better named
19:09:36 <abadger1999> I think it belongs on docs.ansible.com
19:09:51 <felixfontein> gundalow: true, but solving that correctly requires also a huge amount of effort (comparable to the collection migration), and right now there are only two people on the docs team with a lot of other things to do
19:10:09 <gundalow> felixfontein: I only meant have the file else where and link it
19:10:23 <gundalow> anyways, ignore me as I'm the only one saying this :)
19:10:28 <felixfontein> gundalow: but we have exactly the same problem for the porting guide
19:10:29 <cyberpear> they stopped being roadmaps a while ago ... now merely a schedule
19:10:44 <felixfontein> and that one contains more RST so linking to it on github will not provide a good experience
19:11:04 <gundalow> cyberpear: yup, and I think they've always been a single point, rather than a map
19:11:09 <abadger1999> although "who has commit" to that repo might become a concern down the road.
19:11:25 * gundalow slips Ansibullbot a $5
19:11:32 <abadger1999> (I think we can survive that for 2.10, though, and solve it later if it's a problem)
19:11:36 <gundalow> +1
19:11:57 <felixfontein> abadger1999: definitely
19:12:21 <gundalow> OK, so 1) rename existing 2.10 ROADMAP, 2) Add new roadmap file
19:12:36 <gundalow> (I have to drop in a minute, and I see we are at 72/60mins)
19:13:15 <felixfontein> hehe, let's see when we have the first meeting where we finish in time!
19:13:37 <acozine> heh
19:14:02 <acozine> it's good to have stuff to do - much better than ten-minute meetings about nothing
19:14:09 <cyberpear> I foresee trading schedule with core :p
19:14:51 <felixfontein> gundalow: that would be what we're also planning for the porting guide right now
19:14:59 <gundalow> cool
19:15:02 <felixfontein> acozine: indeed!
19:15:25 <felixfontein> cyberpear: I guess eventually it will get more quiet, similar to core meetings after a release ;)
19:16:01 <gundalow> Think that's a while off :P
19:17:21 <gundalow> #agreed `ansible` roadmap will live alongside ansible-base roadmap (which needs renaming)
19:17:28 <gundalow> Anything else before #endmeeting?
19:17:31 <gundalow> #chair
19:17:31 <zodbot> Current chairs: abadger1999 acozine cyberpear felixfontein gregdek gundalow nitzmahone rbergeron samccann
19:17:42 <acozine> not from me
19:17:44 <felixfontein> nothing from my side that can't wait until next week
19:17:48 <abadger1999> Not from me
19:18:21 <samccann> I've got a module version question but i can ask after the meeting is over
19:18:36 <gundalow> #topic Module versioning
19:18:45 <samccann> oh alright
19:19:14 <samccann> i see 'new in 1.0.0' and 'new in 2.8'  and some with nothing
19:19:50 <samccann> Feels confusing for new ansible people to see some reflecting the collection version, and some reflecting an older ansible verson. (and there may be some new in 2.10 there)
19:19:56 <felixfontein> samccann: do you have examples for that?
19:20:08 <cyberpear> "new in" is very helpful when you need to support older versions...
19:20:09 <samccann> in the module docs.  So I'm wondering if we should have a recommendation?
19:20:12 <gundalow> Can we set these to be "too old to be notable"?
19:20:18 <felixfontein> and do you mean version of the module, or version of an option in the collection?
19:20:29 <samccann> our too old to be notable will move to 2.6 or 2.7 I think
19:20:32 <abadger1999> I'd recommend collection version everywhere.
19:20:35 <samccann> version of a module
19:20:44 <gundalow> Can we set these to be "too old to be notable" for two-digit versions
19:20:44 <cyberpear> I think the docs generator has a setting for that
19:20:45 <abadger1999> but I haven't thought long and hard on it
19:20:50 <gundalow> cyberpear: yup
19:20:52 <samccann> http://docs.testing.ansible.com/ansible/2.10/collections/wti/remote/cpm_interface_config_module.html#ansible-collections-wti-remote-cpm-interface-config-module
19:20:54 <felixfontein> in c.g, all modules that used to be in 2.9 have no version_added, and thus won't show anything
19:20:55 <samccann> is a new one in 2.10
19:21:11 <samccann> I saw older ones in my travels as well
19:21:18 <abadger1999> gundalow, cyberpear: Too old to be notable is currently disabled or set really far back in time.
19:21:20 <acozine> the docs generator does have a setting, but if we set it to `2.7` then nothing marked `version_added 1.0.0` will display
19:21:26 * abadger1999 can't remember what he did
19:21:28 <samccann> and of course the ansible-maintained collections all decided to use the collection version starting at 1.0.0
19:21:29 <cyberpear> not a problem as long as I can still go see the older docs
19:21:41 <cyberpear> right now, I think it's 2.5?
19:22:06 <samccann> cyberpear: that sounds right.
19:22:09 <felixfontein> wti.remote.cpm_interface_config definitely has an invalid value for version_added
19:22:11 <abadger1999> cyberpear: in stable-2.9, it is either 2.4 or 2.5 I think.  But in stable-2.10 it is disabled/set really far back
19:22:15 <samccann> out publishing checklist would change that to 2.6
19:22:43 <felixfontein> I'm curious why it isn't showing the collection name next to the version number
19:22:43 <samccann> but sounds like we should just leave it alone
19:22:51 <abadger1999> 17 TOO_OLD_TO_BE_NOTABLE = '0'
19:23:10 <felixfontein> abadger1999: I guess that should only be used for ansible.builtin version numbers
19:24:02 <samccann> the overarching question - does it matter that some collection owners will track the collection version (aka 1.0.0) and some, for now anyway, are tracking the ansible version (2.8, 2.10 etc)
19:24:08 <abadger1999> I think it would be possible to specialcase that in the template.  Although I don't know if it should be specialcased.  It's not a huge burden to see it.
19:24:34 <abadger1999> I would love for all collection owners to to track collection version.
19:24:38 <acozine> would it be clearer to have a different field for collections? `coll_version_added`?
19:25:02 <samccann> well I haven't checked, but these values likely show up in AH as well
19:25:06 <felixfontein> abadger1999: where does ""
19:25:06 <felixfontein> New in version 2.10.
19:25:09 <cyberpear> I don't think it matters much... it'd be fine w collections tracking by related ACD version
19:25:09 <felixfontein> come from?
19:25:12 <samccann> which is 'ansible-free' so to speak.
19:25:16 <felixfontein> (sorry for the bad paste)
19:25:23 <gundalow> If docs are in http://docs.testing.ansible.com/ansible/2.10/collections/ does anyone care if the functionality existed pre-collections?
19:25:38 <acozine> gundalow: oh, that's a good point
19:25:47 <acozine> probably not
19:25:55 <gundalow> I (maybe wrongly) assumed if someone is at http://docs.testing.ansible.com/ansible/2.10/collections/index.html then they are using a collection
19:26:28 <gundalow> Or you'd use http://docs.ansible.com/ansible/2.9/
19:26:34 <felixfontein> gundalow: they could have been sent there by a redirect when switching to 2.10 in the version selector
19:26:37 <cyberpear> I think we should track which features first showed up in the collections version, and which modules didn't exist before the collection
19:26:43 <gundalow> Though maybe there is some path that would redirect people
19:27:23 <gundalow> So does that mean don't display and X.Y
19:27:23 <gundalow> Any module without a version added should default to 1.0.0?
19:27:34 <abadger1999> felixfontein: This? https://github.com/ansible-community/antsibull/blob/main/antsibull/data/docsite/plugin.rst.j2#L169
19:27:41 <cyberpear> (btw, was there consensus on opening the website server configs?)
19:28:00 <abadger1999> There's a few diffrent version_added (the whole module vs individual options).  They'er sprinkled throughout that template.
19:28:19 <felixfontein> abadger1999: I meant this one: https://github.com/ansible-community/antsibull/blob/main/antsibull/data/docsite/plugin.rst.j2#L64-L69
19:28:26 <felixfontein> abadger1999: I'm wondering what happened to the collection name
19:28:29 <felixfontein> I'll investigate later
19:28:57 <samccann> fwiw I just checked AH and it seems it doesn't display version added at all.  At least that wti example above doesn't show version added in 2.10 in AH
19:29:18 <samccann> (AH being the proxy for what galaxy-ng will do I guess)
19:30:01 <felixfontein> https://github.com/wtinetworkgear/wti-collection/blob/master/wti/remote/plugins/modules/cpm_interface_config.py#L31
19:30:03 * gundalow heads off
19:30:11 <gundalow> I'll read scrollback tomorrow
19:30:17 <felixfontein> they explicitly write `version_added: "2.10"` in their docs
19:30:27 <felixfontein> (which is wrong, since 2.10 cannot be a collection version)
19:31:06 <felixfontein> gundalow: bye!
19:32:12 <samccann> felixfontein: yes, isn't that what module owners have always done when adding a new module? put that version field in it?
19:32:18 <cyberpear> maybe make it a dict, that references which collection and or "base/acd"?
19:32:27 <samccann> Only today, some are using a collectoin version and some are using an ansible version
19:32:29 <acozine> cyberpear: no decision to open the website server configs, but this information does not live there
19:32:50 <felixfontein> samccann: they have, but now they need to use the collection version
19:32:55 <cyberpear> so you could track which version of ACD and witch version of
19:33:00 <cyberpear> the collection
19:33:49 <felixfontein> ACD doesn't make sense, since the collection can be used outside of ACD as well
19:34:11 <felixfontein> well, it would be possible to add that info as well, but it would get a lot more complicated
19:34:12 <abadger1999> felixfontein: It's probably the `if doc['version_added_collection'] != collection` portion of the template.
19:34:18 <felixfontein> (especially if they put the wrong versions in there)
19:36:14 <felixfontein> abadger1999: ah yes. I guess we should probably remove that `if`, and always show the collection name
19:36:25 <felixfontein> (that way people will also notice that they put the wrong info in there)
19:36:30 <felixfontein> (if they ever look at the docs)
19:36:36 <cyberpear> I'm saying have multiple versions/ collections/acd listed
19:36:57 <abadger1999> yeah... ansible/acd version looks like it makes sense for the next few months but after that it will become increasingly apparent that it isn't so relatable to facts.
19:37:00 <abadger1999> felixfontein: =1
19:37:06 <cyberpear> (sorry, typing on phone)
19:39:40 <felixfontein> ok, is there more to discuss?
19:40:20 <acozine> I don't think so
19:40:30 <felixfontein> abadger1999: https://github.com/ansible-community/antsibull/pull/148
19:40:34 <abadger1999> (err felixfontein +1 )
19:40:50 <felixfontein> abadger1999: I assumed you meant that ;)
19:41:05 <acozine> that pesky shift key!
19:41:39 <abadger1999> thanks :-)
19:41:59 <samccann> sorry did we finish the version added? got sidetracked. Can you info the decision?
19:42:20 * cyberpear wonders if there's an issue tracking "version_added" discussion
19:42:42 <felixfontein> samccann: I'm not sure what's there to discuss, I thought this was already settled in the past :)
19:43:28 <felixfontein> I think we decided in a docs meeting that version_added should always refer to the current collection's version numbers
19:43:38 <acozine> changes in collections should use the collection version numbers
19:43:47 <felixfontein> https://github.com/ansible/community/issues/521#issuecomment-624153545
19:43:52 <samccann> ok but that's not happening so...?
19:44:03 <felixfontein> that says "for new features in the module docs, version_added should refer to the collection version moving forward" though
19:44:06 <samccann> I'm assuming it should happen for 2.10 modules anyway
19:44:21 <samccann> ah so something for post-2.10 then?
19:44:22 <felixfontein> and nothing about "existing" things (though 2.10 isn't really fitting into the "existing" category)
19:44:59 <cyberpear> In that case, I'd say we should track `version_added` for things that first appeared in a collection, and if it first appeared in ansible/ansible, it should not have a `version_added` attribute.
19:45:00 <felixfontein> samccann: I think 2.10 does not fit into the "existing" category, so "version_added: '2.10'" should only appear in ansible-base
19:45:30 <cyberpear> `version_added: 2.10` on a collection item should be translated into `version_added: 1.0.0` or so, IMO
19:45:31 <felixfontein> cyberpear: content in ansible/ansible should also have version_added (but with the ansible-base version)
19:45:49 <felixfontein> cyberpear: we cannot make this conversion automatically, the collection maintainer need to fix their version_added values
19:45:59 <cyberpear> right... I guess I was referring to stuff that got moved from a/a into a collection
19:46:24 <felixfontein> cyberpear: during migration, all version_added have been removed
19:46:35 <felixfontein> except of course when content was migrated manually....
19:46:39 <cyberpear> felixfontein: even ones that were 2.10?
19:46:48 <samccann> #action samccann add to the collection checklist that version_added should not say 2.10, but should say collection version
19:46:52 <felixfontein> cyberpear: unfortunately these too. I manually re-added them for c.g, c.n and c.c
19:46:58 <cyberpear> IMO, ones that were 2.10 should be added back as 1.0.0 (or whatever collection version)
19:47:04 <felixfontein> IMO too
19:47:11 <felixfontein> (that's why I did that work for c.g, c.n and c.c)
19:47:18 <cyberpear> felixfontein++
19:48:30 <samccann> if folks are in agreement, I'll add it to gundalow's collection checklist of requirements to be in ansible 2.10 (can't find the tracking issue off the top of my head)
19:49:01 <acozine> samccann: +1
19:49:36 <felixfontein> samccann: sounds like a good idea!
19:49:46 <felixfontein> I'll also add a post to the issue with important stuff for collection maintainers
19:50:30 <felixfontein> (this one: https://github.com/ansible-collections/overview/issues/45)
19:50:40 <abadger1999> thanks, samccann !
19:53:51 <acozine> are we still "in a meeting"?
19:54:06 <samccann> yeah. blame me for that one :-)
19:54:15 <acozine> heh
19:54:28 <acozine> anything else? or is it time . . . for an official endpoint?
19:55:01 <acozine> going once . . .
19:55:13 <acozine> going twice . . .
19:55:36 * acozine bangs gavel on the table
19:55:43 <acozine> thanks everybody!
19:55:48 <acozine> #endmeeting