18:01:16 #startmeeting Ansible Community Meeting 18:01:16 Meeting started Wed Sep 14 18:01:16 2022 UTC. 18:01:16 This meeting is logged and archived in a public location. 18:01:16 The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:01:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:16 The meeting name has been set to 'ansible_community_meeting' 18:01:17 #topic Agenda https://github.com/ansible/community/issues/645 18:01:17 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping! 18:01:20 #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics 18:01:23 #topic Updates 18:01:46 o/ 18:01:50 o/ 18:02:14 .hello gotmax23 18:02:14 gotmax[m]: gotmax23 'Maxwell G' 18:02:26 I may have to leave early, but I'm here for now 18:02:42 .hello samccann 18:02:43 samccann: Sorry, but user 'samccann' does not exist 18:02:59 HAH! now I'm having an existential crisis...;-) 18:03:00 It only works if you're registered with the Fedora Accounts System 18:03:07 #chair cyberpear samccann gotmax[m] 18:03:07 Current chairs: cyberpear felixfontein gotmax[m] samccann 18:03:08 ah gotcha. thanks 18:05:27 I hope everyone had a nice day so far :) 18:06:04 You too :) 18:06:10 #info ansible-core feature freeze (for 2.14) is coming Monday, September 19 18:06:22 dun da dun dun!! 18:06:43 o/ 18:06:44 ^^ somewhere between menacing music and a drum roll 18:06:58 #info one week later the first ansible-core 2.14 beta, and then the first Ansible 7 alpha, will be released 18:08:24 it's a busy month! 18:08:49 btw, anyone knows when this week's Ansible 6.4.0 release will happen? 18:08:50 indeed! 18:08:53 #chair acozine 18:08:53 Current chairs: acozine cyberpear felixfontein gotmax[m] samccann 18:09:27 Where is the schedule for when the next releases are supposed to happen? I think it's every three weeks or something? 18:10:13 o/ 18:10:41 #chair briantist 18:10:41 Current chairs: acozine briantist cyberpear felixfontein gotmax[m] samccann 18:11:04 gotmax[m]: I don't think there's an explicit schedule, there's only "every three weeks", and this week is three weeks after the last release :) 18:11:19 * gotmax[m] nods 18:11:37 most ansible releases were happening on Tuesday, but Wednesday is also not very uncommon 18:11:44 from experience :) 18:12:27 Maybe we should create a specific schedule 18:13:13 chadams announced the last one so might know when the next Ansible package release is coming 18:13:42 yeah, my next question would be who is actually supposed to do the release :) 18:14:01 because last time it was someone else than Ompragash 18:15:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:15:27 * felixfontein is just looking at the community issues 18:17:22 basically everything recent is about removing stuff from the ansible package ;) 18:17:47 by either removing collections (unmaintained ones), or by removing files :) 18:17:55 heh, it's time to slim down a bit, I guess 18:18:07 Yup :) 18:19:11 For the extra files, I think we're just waiting to hear back from legal at this point 18:19:40 felixfontein: members of the Productization team and I will be doing the ansible community releases on rotation. I talked to ompragash yesterday about the cadence of these releases. The Ansible Core releases happen every 4 weeks, and my understanding from samccann is that the aim is to release Ansible (community) 3 weeks after the core release so that the core patch version lines up with the community minor version. 18:21:37 hmm, that is news to me at least 18:21:42 chadams: that was for the major release cadence. Sorry if I wasn't clear. I'm not sure if the minor package releases wait those 3 weeks as well 18:22:13 So Ansible 7 won't release a few weeks after core 2.14 18:22:34 won't release UNTIL a few week after... 18:22:54 according to https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_7.rst#release-schedule it's 3 weeks between 2.14.0 and 7.0.0, and 2 weeks between 2.14.1 and 7.1.0, for example 18:23:03 From my experience, ansible minor releases come a couple days-a week after ansible-core releases 18:23:38 * gotmax[m] wonders why the community team no longer does the releases 18:23:43 gotmax[m]: it basically changes between a day, a week, and two weeks 18:23:53 since core releases every four weeks, and Ansible every three weeks 18:24:19 actually or three weeks, depending on how you look at it 18:24:25 wow that's more complicated than I thought 18:25:05 basically we decided on every three weeks back when ansible-core was also releasing every three weeks 18:25:42 Ahh ok. 18:25:42 gotmax (He/Him) , Ompragash will still be sharing releases. Just time allocation & sharing of duties. 18:25:49 then ansible-core switched to every four weeks, but ansible didn't change - I guess part of the idea was to make it more obvious that the versions of ansible and ansible-core are not really related 18:26:13 which I guess is not *that* important anymore since we have ansible-core 2.13.x and Ansible 6.x.y.0 right now 18:26:42 it definitely makes sense that it's not just one person always doing the work :) 18:26:50 (think of PTO and stuff...) 18:26:58 Agreed 18:28:13 We can definitely stick with the existing schedule if that is preferred. But it might be a good time to pivot and align with core better if that makes sense to folks. I am happy to talk it through either way. 18:28:28 ompragash: what are your thoughts? 18:28:39 I guess that would be an interesting new discussion to start :) 18:28:48 Do we know how many folks download the point releases? 18:29:00 though I guess that for Ansible 6 we should stick to the current 3 weeks cycle, and only start with every 4 weeks with Ansible 7 18:29:09 chadams: if we want to bring new schedule I think we can save it for Ansible 7 18:29:29 acozine: Everyone who's using distribution packages probably does 18:29:51 I guess it's impossible to know who is downloading for hte first time and who is upgrading. Scratch my question. 18:29:58 gotmax (He/Him): yeah, that too 18:30:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:30:28 * new schedule then I think 18:31:43 ompragash: that makes sense. I agree, let's stick to every 3 weeks for Ansible 6. Want to work together to release tomorrow morning? 18:32:35 chadams: sure! let's meet tomorrow morning:) 18:33:08 Sounds good! Sorry for any confusion I caused y'all : ) 18:33:24 No problem 18:33:32 nahh it's all good 18:33:42 * gotmax[m] notes that there's 3258 different license files in the ansible package 18:34:53 Oops that's wrong 18:35:11 gotmax[m]: different locations, or distinct file contents? 18:36:18 There's 202 18:36:34 That's the number of total files. 18:37:14 I think we should find a way to share them between collections in the ansible package 18:37:47 do they all reference the same license? 18:37:50 All of these files 3.5 mb to the package, which is nontrivial 18:38:44 There's at least one copy of the GPL for each collection 18:39:46 Could that become a link in the collection README, or a line in the galaxy.yml? 18:39:54 is there a legal issue involved here, where we are required to keep the license with the code so to speak? 18:40:10 Then there's the secondary licenses that apply to some collections: BSD-2-Clause, BSD-3-Clause, Apache-2.0, MPL-2.0, PSF-2.0 18:40:26 one problem is that the Python packaging process converts symlinks into copies 18:40:46 Yes, but I don't think any of those were symlinks in the first place 18:40:53 heh, symlink all you want, we're including the file anyway? 18:41:14 And many of them have slight formatting differences 18:41:15 gotmax[m]: some were, namely the links to ../COPYING in LICENSES/ in some collections like community.general :) 18:42:07 That's true 18:42:43 In my ideal world, we could have one LICENSES directory for the whole package and have each collection follow REUSE 18:42:47 But I'm not holding out hope... 18:42:58 due to Python packaging always destroying symlinks, I'm not sure there's much we can do if we don't want to modify collection contents 18:43:12 Yeah, it's a bit sticky 18:44:41 "All of these files 3.5 mb to the..." <- The real count is 6.2 mb 18:44:59 I cut half of it off by running `hardlink` over all of the licenses 18:45:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:45:04 in the Fedora package 18:47:24 I don't think we can solve this without standardized license handling between collections. Even with that, we'd still have to consolidate the files. 18:47:39 I more so wanted to bring it to everyone's attention 18:48:44 should we document the "lightest-weight way to include license files in your collection" somewhere? 18:49:14 if there's a better way to do it, pointing that out may get the community moving in the right direction over time 18:50:02 Well, if every collection used the same exact license texts (no formatting differences), hardlinking them would be more effective 18:51:20 There's ~66 different versions of the GPL in the collection each with slight formatting difference 18:51:42 s/collection/ansible package/ 18:52:02 hmm, 66 is a lot more than I would expect 18:52:30 (I would have expected maybe 5-10 different versions at most) 18:55:47 For BSD/MIT style license texts, they're usually different due to the embedded copyright statements. But we can at least use the same GPL text for every collection. 18:57:36 Wow, 66 is a lot. If you replace them with the same version, is gwgre much of a `diff`? Just wondering if it's whitespace? 18:59:06 It could be white space, indentation, or different FSF URLs 19:00:33 well, I guess time's up for today :) 19:01:03 thanks for running the meeting felixfontein 19:01:08 time flies when you're having (licensing) fun, eh? 19:01:24 haha yes :) 19:01:25 Yup :) 19:01:38 it's even faster than when you're having semantic markup fun ;) 19:01:41 #endmeeting