19:00:20 <felixfontein> #startmeeting Ansible Community Meeting
19:00:20 <zodbot> Meeting started Wed Dec 14 19:00:20 2022 UTC.
19:00:20 <zodbot> This meeting is logged and archived in a public location.
19:00:20 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:21 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:21 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/645
19:00:28 <felixfontein> acozine, andersson007_, anwesha, baptistemm, bcoca, briantist, cidrblock, cyberpear, cybette, dericcrago, dmsimard, felixfontein, geerlingguy, gotmax, gundalow, gwmngilfen, ikhan_, jillr, jtanner, lmodemal, mariolenz[m], markuman, maxamillion, misc, nitzmahone, oranod, resmo, russoz, samccann, thaumos, zbr: The Ansible community meeting is starting now!
19:00:33 <felixfontein> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself.
19:00:36 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
19:00:39 <felixfontein> #topic Updates
19:00:53 <maxamillion> .hello2
19:00:53 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
19:00:57 <anwesha> hello hello
19:01:07 <cybette_> o/
19:01:09 <gotmax> .heloo gotmax23
19:01:13 <gotmax> .hello gotmax23
19:01:14 <zodbot> gotmax: gotmax23 'Maxwell G' <gotmax@e.email>
19:01:23 <gotmax> ha, was just about to start the meeting it
19:01:35 <briantist> o/
19:02:22 <oranod> o/
19:02:25 <oranod> hello
19:02:27 <felixfontein> #chair maxamillion anwesha cybette_ gotmax briantist oranod
19:02:27 <zodbot> Current chairs: anwesha briantist cybette_ felixfontein gotmax maxamillion oranod
19:02:33 <gotmax> #info Please vote on "[Vote ends on 2022-12-16]  Removal from Ansible 9: cyberark.pas": https://github.com/ansible-community/community-topics/discussions/172
19:02:52 <cybette_> #info ansible-core 2.15.0 Schedule Change https://groups.google.com/g/ansible-devel/c/KtGFm6fCB7U
19:02:55 <gotmax> There's only four votes and the vote ends on Friday
19:03:20 <mariolenz[m]> o/
19:03:21 <felixfontein> reminds me that we need to create a schedule for Ansible 8
19:03:26 <felixfontein> #chair mariolenz[m]
19:03:26 <zodbot> Current chairs: anwesha briantist cybette_ felixfontein gotmax mariolenz[m] maxamillion oranod
19:03:27 <cybette_> #info Ansible community package holiday release schedule https://groups.google.com/g/ansible-devel/c/htFjU7jZVYA
19:03:30 <gotmax> Yeah
19:03:40 <gotmax> Should we discuss that today?
19:04:20 <felixfontein> sure, why not?
19:04:34 <cybette_> +1
19:05:07 <anwesha> +1
19:05:09 <gotmax> the ansible-core release schedule is even worse than last time, so I'm not sure I'll be able to get Ansible 8 into F38 :/
19:05:20 <gotmax> *Worse for Fedora
19:06:05 <gotmax> 2.15.0 will be released a month after F38 and then we'll probably be stuck with unsupported Ansible 7 for 13 months
19:06:11 <gotmax> Anyways...
19:06:42 <gotmax> #topic Ansible 8 Release Schedule
19:06:58 <gotmax> #info ansible-core 2.15's release schedule is at https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_15.rst
19:07:00 <gotmax> #link https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_15.rst
19:07:12 <acozine> o/
19:07:29 <gotmax> #chair acozine
19:07:29 <zodbot> Current chairs: acozine anwesha briantist cybette_ felixfontein gotmax mariolenz[m] maxamillion oranod
19:07:35 <samccann> 0/
19:07:50 <gotmax> #chair samccann
19:07:50 <zodbot> Current chairs: acozine anwesha briantist cybette_ felixfontein gotmax mariolenz[m] maxamillion oranod samccann
19:07:51 <felixfontein> #chair samccann
19:07:51 <zodbot> Current chairs: acozine anwesha briantist cybette_ felixfontein gotmax mariolenz[m] maxamillion oranod samccann
19:09:15 <felixfontein> so basically ansible-core 2.15.0b1 is released on 2023-04-03, which would make Ansible 8.0.0a1 2023-04-04. 2.15.0rc1 is three weeks after that, so 8.0.0b1 will be on 2023-04-25 if we follow our previous schedules
19:10:07 <felixfontein> 2.15.0 is three weeks after rc1, so we'd have 8.0.0rc1 on 2023-05-16
19:10:25 <felixfontein> and if we continue as with Ansible 7, we'd have the 8.0.0 release two weeks after that
19:10:26 <acozine> that seems reasonable
19:10:49 <felixfontein> hmm, or even one week less?
19:11:21 <felixfontein> no wait, I'm somewhat confused
19:11:42 <gotmax> yeah, last time we had a week between ansible 7.0.0rc1 and 7.0.0 GA
19:11:47 <felixfontein> 8.0.0b1 + feature freeze would be on 2023-05-16, one day after 2.15.0 GA
19:12:08 <felixfontein> so 8.0.0rc1 one week after that, and 8.0.0 GA one week after that again
19:12:17 <felixfontein> (assuming rc1 doesn't expose blockers)
19:14:06 <felixfontein> does that sound reasonable?
19:14:28 * gotmax is refreshing himself on what happened for 7.0.0
19:15:01 <gotmax> okay, I see now
19:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
19:15:38 <gotmax> I'm fine with what we did last time, but I wonder if we should shorten the delay between 2.15.0 and 8.0.0 to one week instead of two weeks
19:15:40 <mariolenz[m]> I think we should open an issue / community topic to discuss this. I don't think I could decide what we should do at the spur of the moment.
19:16:07 <gotmax> yeah, me neither. I think this is just starting the discussion
19:16:13 <cybette_> yep
19:16:24 <felixfontein> yes, if nobody has complaints the next step would be to create a disucssion issue for this
19:16:38 <felixfontein> and potentially an ansible/ansible PR with a concrete proposal
19:17:03 <samccann> sounds good
19:17:22 <cybette_> would it make more sense to have 8.0.0b1 after 2.15rc1 instead of 8.0.0a2 after 2.15rc1 ?
19:17:25 <felixfontein> hmm, so instead of 8.0.0b1 you would go directly for 8.0.0rc1?
19:17:30 <gotmax> is anyone amendable to shorting the delay to one week? I'm prosing 8.0.0rc1 the day after 2.15.0 and 8.0.0 GA the week after.
19:18:13 <acozine> I don't mind either way, but then I don't lift a finger for the releases, so my opinion doesn't carry a lot of weight
19:18:13 <felixfontein> cybette_: I would only do b1 after feature feeze, and that has traditionally been on ansible-core GA
19:18:23 <cybette_> and then 8.0.0rc1 after 2.15 GA, folloewd by 8.0.0 GA a week later
19:18:27 <felixfontein> gotmax: I don't like skipping b1
19:18:44 <cybette_> felixfontein: got it, makes sense
19:19:05 <felixfontein> having b1 earlier would mean to move feature freeze earlier
19:19:17 <gotmax> yes, it would
19:19:24 <felixfontein> I guess we could do that, but then we risk that feature freeze is before ansible-core is final
19:19:54 <felixfontein> IMO feature freeze should not be before ansible-core's rc1
19:19:58 <mariolenz[m]> gotmax: Since we're trying to release ansible 7.x one or two days after ansible-core 2.14.x, shouldn't we aim to release 8.0.0 even sooner than one week after 2.15.0?
19:20:50 <samccann> wouldn't we want some testing time between 2.15.0 GA and 8.0.0 GA?
19:20:57 <felixfontein> mariolenz[m]: I would really avoid that, 2.15.0 is after all  new major release, and some collections might need more time to get ready for it
19:21:13 <samccann> I don't know what might go wrong but it is a major core update so seems to me it might take more work to get it out
19:21:29 <samccann> ok what felixfontein said :-)
19:22:07 <gotmax> mariolenz[m]: IIRC two releases ago (6) there was a three week delay between 2.13.0 and 7.0.0. last release (7) there was a two week delay between 2.14.0 and 7.0.0.
19:22:12 <cybette_> right, for minor releases it's ok, but for major release there should be more testing time between core and ansible
19:22:18 <felixfontein> I find one week pretty short, but I can live with that. but only 1-2 days is way too short IMO :)
19:22:25 <gotmax> I don't think it should be any less than a week delay
19:22:51 <gotmax> but I understand the reasoning for keeping it at two weeks to allow for more testing and for collections to prepare for the new release
19:23:07 <felixfontein> actually for Ansible 6 it was five weeks between 2.13.0 and 6.0.0
19:23:22 <felixfontein> (2022-05-16 to 2022-06-21)
19:23:41 <felixfontein> (though that was because ansible-core 2.13.0 was moved one week earlier quite late in the schedule)
19:23:42 <gotmax> hmm. my memory seems to be failing me today :).
19:23:42 <cybette_> was it only half a year ago? :D
19:23:51 * gotmax needs to get more sleep
19:24:04 <anwesha[m]> Does this Road map look good? https://share.riseup.net/#KufCU9lJxIaPx_jD4xZZ8Q
19:24:20 <felixfontein> for Ansible 5 it was three weeks though (https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_5.rst#release-schedule)
19:24:47 <gotmax> and the original plan for 7.0.0 had a three week delay that we shortened to two weeks.
19:25:20 <gotmax> i guess I'm convinced that two weeks is a good middle ground
19:25:57 <samccann> anwesha: - the core GA is listed at 05/25 but 8rc1 is 5/16 (aka before GA)
19:26:35 <cybette_> anwesha: I think line 3 should say 8.0.0a2 instead of 8.0.0b1
19:26:38 <gotmax> core ga is the 15th now
19:27:36 <cybette_> they announced the change couple days ago
19:27:58 <felixfontein> https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_15.rst are the latest core dates
19:29:55 <mariolenz[m]> cybette_: https://groups.google.com/g/ansible-devel/c/KtGFm6fCB7U
19:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
19:30:42 <gotmax> I guess we should find a volunteer to create a draft schedule and a community-topics ticket after the meeting and move on now
19:30:54 <felixfontein> true. is anyone volunteering? :)
19:31:03 <felixfontein> I can do it if nobody else wants
19:31:34 <acozine> I can take that on
19:31:49 <cybette_> I've updated the paste https://share.riseup.net/#dT4bGLZM4bkhYl0hY723cw
19:33:07 <acozine> cybette: thanks! I'll copy that into the docs PR and community-topics ticket
19:33:26 <gotmax> cybette_: that looks good to me at first glance
19:33:29 <gotmax> thanks!
19:33:39 <cybette_> thanks acozine ! and thanks to anwesha for creating the initial draft
19:33:52 <felixfontein> cybette_: looks good, except that I would move feature freeze to the same day as 2.15.0 GA - or move the 8.0.0b1 release one day after feature freeze
19:34:25 <felixfontein> feature freeze should be one day before the release, so that a release made on that day in any timezone will make it into the release
19:34:43 <gotmax> And add "Ansible core 2.15.0rc1 2023-04-24" above 8.0.0a2
19:34:54 <felixfontein> (otherwise we'd have to specify an exact time + timezone on that day when feature freeze happens)
19:35:26 <felixfontein> and it is "ansible-core", not "Ansible core" or "Ansible-core" :)
19:35:50 <gotmax> > <gotmax> And add "Ansible core 2.15.0rc1 2023-04-24" above 8.0.0a2 | done
19:35:52 <samccann> aNsIbLe-CoRe
19:35:52 <cybette_> felixfontein how about now https://share.riseup.net/#PVYGShqyOmUuafxYiOtBzQ
19:36:44 <felixfontein> cybette_: looks good to me, up to the spelling of ansible-core ;)
19:36:46 <felixfontein> samccann: :D
19:39:05 <gotmax> so I guess we can move this to a ticket and go to open floor?
19:39:17 <felixfontein> #topic Ansible PYPi description
19:39:22 <felixfontein> #link https://github.com/ansible-community/community-topics/issues/173
19:39:57 <gotmax> ah, my thing. I forgot about that :)
19:39:58 <felixfontein> Please look at the PR https://github.com/ansible-community/antsibull/pull/474 and discuss if you have wishes, ideas, or other things for Ansible's PyPi description (https://pypi.org/project/ansible/)!
19:40:02 <felixfontein> hehe :)
19:40:04 <cybette_> It's PyPI not PYPi ;)
19:40:08 <cybette_> hehe
19:40:23 <jtanner> hi
19:40:44 <felixfontein> right...
19:40:47 <felixfontein> #chair jtanner
19:40:47 <zodbot> Current chairs: acozine anwesha briantist cybette_ felixfontein gotmax jtanner mariolenz[m] maxamillion oranod samccann
19:40:53 <gotmax> One point of discussion is what we should do with the Design Prinicples
19:41:13 <gotmax> https://github.com/ansible-community/antsibull/blob/b93294f5500cc8fa19829eb1a8aab3ffec30510f/src/antsibull/data/ansible-readme.rst#design-principles
19:41:19 <gotmax> Currently, they're the same as ansible-core
19:41:40 <gotmax> mariolenz[m] suggested we add some of our own for the community package, and I tend to agree
19:42:11 <felixfontein> how about "All batteries included"? :)
19:42:28 <jtanner> all AA batteries
19:42:57 <jtanner> connect them in series to get whatever other voltages needed =)
19:43:50 <gotmax> maybe "Provide a curated bundle of quality collections that conform to the Collection Requirements"
19:44:14 <felixfontein> with the last two words being a link?
19:44:19 <gotmax> sure
19:44:20 <felixfontein> sounds good to me
19:45:07 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
19:45:21 <gotmax> https://github.com/ansible-community/antsibull/pull/474#issuecomment-1352055098
19:45:55 <mattclay> I'd drop "quality" from the description.
19:46:46 <felixfontein> it is true that there are a lot of not very high quality things in the Ansible package...
19:47:09 <samccann> curated gives the notion that it's not just a random list. We could just keep that wording
19:47:32 <mattclay> Yes, I think the parts about being curated and conforming to the requirements are both good.
19:48:36 <mattclay> That way we're being fairly objective with the description, and not implying a particular level of quality that would seemingly apply to all the content.
19:48:45 <gotmax> Ack
19:49:46 <gotmax> I'd also like to save some time for https://github.com/ansible/ansible-hub-ui/pull/3020 :)
19:50:22 <kristianheljas> Perhaps batteries could be linked to https://docs.ansible.com/ansible/latest/collections/all_plugins.html to make clear that AAA batteries are not icluded?
19:50:44 <jtanner> bazaar, not cathedral
19:51:53 <felixfontein> kristianheljas: I would probably not mention batteries at all :)
19:52:19 <gotmax> yeah. also, "batteries included" and "curated" are somewhat contradictory
19:52:30 <felixfontein> ok, if there are more ideas, please write them in https://github.com/ansible-community/antsibull/pull/474, or https://github.com/ansible-community/community-topics/issues/173 for more meta discussions
19:52:47 <felixfontein> gotmax: do you want https://github.com/ansible/ansible-hub-ui/pull/3020 as a separate topic, or in open floor?
19:52:56 <gotmax> separate I think
19:53:11 <felixfontein> #topic https://github.com/ansible/ansible-hub-ui/pull/3020
19:53:40 <jtanner> the voting and discussion on that should happen in a community ticket. i'm going to merge 3020 soon and it'll be set to legacy until you all figure out a new name
19:53:56 <gotmax> #info the question here is whether we should refer to roles as `standalone roles`, `legacy roles`, or something else in the Galaxy NG UI.
19:55:28 <gotmax> jtanner: Would it be possible to make the top level `Standalone Roles` and then have `Roles` and `Namespaces` like I proposed in https://github.com/ansible/ansible-hub-ui/pull/3020#issuecomment-1350065294 ?
19:56:19 <gotmax> Standalone and Legacy are adjectives. Collections is a noun. I think having Standalone or Legacy on its own is confusing.
19:57:05 <jtanner> "collections" doesn't really make sense either ... i think that was just a throw in placeholder to conform to what is "ansible" on the console.redhat instance
19:57:55 <jtanner> also, things like "api token management" make no sense under a "collection" drop down
19:58:10 <maxamillion> +1
19:58:10 * felixfontein is still confused what 'legay/standalone namespaces'... I think I once knew, but then forgot again :)
19:58:54 <jtanner> namespaces in the collection world are highly restrictive on the naming conventions and many of the v1 namespaces got in long before those restrictions were made
19:58:56 <gotmax> Yeah, `Repository Management` and `API token management` shouldn't be part of `Collections`
19:59:04 <felixfontein> (was it just the list of all namespaces used for roles, that might have characters in them that are not allowed otherwise?)
19:59:21 <felixfontein> jtanner: so it's basically namespaces for roles?
19:59:33 <jtanner> namespaces for $CONTESTED_PREFIX roles
19:59:47 <felixfontein> yeah, that's what I mean ;)
20:00:10 <felixfontein> would it be possible to use the prefix 'standalone' for roles and 'legacy' for namespaces?
20:00:24 <jtanner> i guess so ...
20:00:37 <jtanner> it's just javascript string formatting
20:01:21 <felixfontein> I think standalone is a very good prefix for roles, but I'm not sure yet about namespaces...
20:01:45 <gotmax> I just don't think the top-level `Legacy` heading on its own w/o a noun makes sense and don't necessarily like referring to roles as legacy
20:01:52 <samccann> what can a v1 namespace do besides roles?
20:01:54 <felixfontein> anyway, gotmax, do you want to create a community discussion item for this so we can collect and discuss proposals?
20:02:02 <gotmax> okay
20:02:38 <acozine> I've done the roadmap stuff. Community topic: https://github.com/ansible-community/community-topics/issues/176 and docs PR: https://github.com/ansible/ansible/pull/79598
20:02:45 <gotmax> #action gotmax23 to create a community-topics ticket about whether Galaxy NG should use the term `Standalone Roles` or `Legacy Roles`
20:02:47 <felixfontein> acozine: thanks a lot!
20:03:06 <jtanner> samccann: nothing other than define the owners of that namespace and by proxy the roles
20:03:08 <samccann> acozine++
20:03:18 <felixfontein> ok, I think it's time to close the meeting
20:03:20 <acozine> now we figure out which updates I missed and which dates I got wrong ;)
20:03:29 <felixfontein> please continue the discussion in the corresponding issues if you want it to be recorded :)
20:03:39 <samccann> so if the only v1 namespaces are for v1 roles.. makes sense to name them the same thing (standalone) imo
20:03:52 <samccann> ;-)
20:04:00 <gotmax> felixfontein: ack
20:04:30 <acozine> thanks for running the meeting felixfontein !
20:05:01 <felixfontein> #endmeeting