18:00:17 #startmeeting Ansible Community Meeting 18:00:17 Meeting started Wed Aug 10 18:00:17 2022 UTC. 18:00:17 This meeting is logged and archived in a public location. 18:00:17 The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:00:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:17 The meeting name has been set to 'ansible_community_meeting' 18:00:17 #topic Agenda https://github.com/ansible/community/issues/645 18:00: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:00:21 #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics 18:00:22 o/ 18:00:24 #topic Updates 18:00:30 o/ 18:00:38 #chair andersson007_ mariolenz[m] 18:00:38 Current chairs: andersson007_ felixfontein mariolenz[m] 18:00:49 o/ 18:00:59 .hello gotmax23 18:01:00 gotmax[m]: gotmax23 'Maxwell G' 18:01:10 o/ 18:02:09 #chair samccann gotmax[m] cybette_ 18:02:09 Current chairs: andersson007_ cybette_ felixfontein gotmax[m] mariolenz[m] samccann 18:02:15 #info there are at least 4 collections available for inclusion review, so any eyes would be much appreciated. See https://github.com/ansible-collections/ansible-inclusion/discussions/categories/second-review-needed and https://github.com/ansible-collections/ansible-inclusion/discussions/categories/new-collection-reviews and 18:02:26 the last and is extra 18:03:42 also thanks folks for introducing milestones in ansible-build-data 18:03:59 apropos milestones, should I remove the 'GA' from their name? 18:04:24 maybe change `GA` to `Prerequisites` ? 18:04:31 otherwise it's unclear a bit 18:05:11 Why not both? 18:05:14 there are multiple points of interest anyway: basically there's the point of time when the data directory is created (usually around the release of the previous version), and there's the time when the first alpha is released 18:05:19 and then there's GA 18:05:21 both is also fine 18:05:32 I'm not sure whether we actually need the GA milestones, I think the other two are more relevant 18:07:11 one point - core uses milestones as a way to designate a 'snapshot' in time for devel. 18:07:31 Do we risk confusion by calling out project milestones here, or is this something only the package developers will see/follow? 18:07:48 samccann: What type of confusion? 18:07:53 o/ 18:07:56 sorry I'm late 18:08:01 #chair acozine 18:08:01 Current chairs: acozine andersson007_ cybette_ felixfontein gotmax[m] mariolenz[m] samccann 18:08:03 * gotmax[m] waves to acozine 18:08:04 no problem:) 18:08:24 Hi gotmax (He/Him)! 18:09:33 can we just call it `Ansible 8.0 Prerequisites` or whatever instead of Prerequisites saying that the issues have to be done before (any) release of Ansible 8.0 ? 18:10:09 i.e. before the point of no return 18:10:12 why not call it the Ansible 8.0.0a1 milestone then? that will be the very first release 18:10:17 gotmax (He/Him): if someone used to core is using their milestone branches and then thinks hey - I can get a 'milestone branch' for Ansible the package 18:10:18 just tossing it out there. I may be exaggerating anyone's confusion 18:10:30 felixfontein: SGTM 18:10:39 I didn't even know that core had milestone branches, so... 18:10:43 +1 18:11:24 felixfontein: What if we/you also want to track tasks between alpha and GA? 18:11:35 I renamed the milestones to X.0.0a1: https://github.com/ansible-community/ansible-build-data/milestones 18:11:38 since I'm being the word-pain today - prerequisites from a user perspective has connotations as well that have nothing to do with what the list is (things that must complete before Ansible 8 releases) 18:12:05 gotmax[m]: we can call it Ansible 8.0.0a1-GA 18:12:17 Just a random heading of "Ansible 8 prerequisites' makes me think -= oh, are they changing the python requirements, etc 18:12:23 gotmax[m]: I'm not sure we'll have tasks to track then - maybe we should not create milestones yet for them, but do that when we find out we actually need them? 18:12:43 +1 18:12:47 again, same comment - I haven't had a chance to READ the stuff y'all are talking about, so if no user, potential user ever sees this, then I can hush up 18:13:15 samccann: no user should see it, I think 18:13:18 I don't think users will confuse that. It on the development issue tracker. 18:13:19 samccann: i think it's only for us 18:13:28 I think X.0.0.a1 makes sense because we should implement as many breaking changes in the a1 release as possible. 18:13:34 i.e. not to forget 18:13:48 mariolenz[m]: +1 18:13:51 And I don't think prereq. really has that connotation 18:14:07 Also, core already is changing its Python requirement... 18:14:25 Instead of implementing them in later releas like beta or RCs. 18:14:28 that's actually something we have to remember 18:14:48 next question is how to force ourselves recall to look at the milestones:) 18:15:00 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:15:19 Prereqs mean something very specific in documentation that is not release requirements for Ansible 8 18:15:58 andersson007_: Solution: ansible playbook on a cronjob that uses `community.general.matrix`. 18:16:00 :) 18:16:07 btw there's a related PR-reminder https://github.com/ansible-community/ansible-build-data/pull/153, can we merge it? 18:16:12 regarding Python requirements I created https://github.com/ansible-community/ansible-build-data/issues/154 for Ansible 7.0.0a1 18:16:20 gotmax[m]: it will work:) 18:16:41 samccann: Well, but if we call the milestone 8.0.0a1 we're not using "prequs" :-) 18:16:53 heh cool 18:18:05 let's start with "Ansible X.0.0a1" and if there's any confusion, we'll think about other options later 18:18:08 ? 18:18:09 Damn, what's "prequs"? I meant "prereqs". 18:18:19 heh 18:18:34 we need to create a definition for "prequs" 18:18:42 "Ansible 8.0.0a1 GA PRQS" 18:18:44 andersson007_: +1. We've already spent a lot of time figuring out issue naming... 18:19:49 Yerp, let's start with a1 and add more milestones if they look necessary. I wouldn't add too many milestones at the moment. If they turn out to be unneccessary, we're still stuck with them. 18:19:57 +1 18:20:32 sounds good to me. we could also simply delete them if we see we don't need them, but also creating new ones is very simple, so let's better create new ones on demand 18:20:33 +1 for adding as needed 18:21:18 OK, how about other kinds of decision implementation tracking? A board maybe? 18:22:00 there's an abandoned project https://github.com/orgs/ansible-community/projects/2/views/5 18:22:12 we could update it 18:22:21 add a view for tasks to be done 18:22:28 any ideas? 18:23:04 projects are only good if there is at least one person actively keeping them up to date 18:23:57 i could but it would mean I'll be supposed to implement all:) 18:24:44 so-so perspective 18:24:45 yeah that's a good point. someone has to maintain it for the long haul. 18:25:00 Personally, I've never seen a (Kanban or other) board that really worked for we. I'm not saying they're a bad idea, but I never was able to really works with them. 18:25:50 Might be my problem, so I'll keep out of this discussion. 18:25:56 I'm trying to get used to it now 18:26:02 I've used projects and been happy with them, but only when +/- 3 folks are committed to maintenance 18:26:11 +1 18:26:49 I'm OK with doing maintenance myself but what's the point to do it if no one looks at it:) 18:27:02 yep 18:27:04 besides me.. 18:27:05 true 18:28:06 if someone is assigned, i could remind but it wouldn't feel good imo as it's all volunteer 18:28:57 or maybe it's ok if a person self-assigned, i.e. committed to solve the task but has forgotten 18:29:25 or if they lost wish, someone else can pick it up 18:30:00 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:30:12 I think reminders in the form of 'ping, are you still working on this?' are ok, so we can find out when some task is abandoned 18:30:23 andersson007_: it's definitely okay to ping someone on anything that is required for the release. For other things w/o a fixed deadline, yeah it's a balance between asking if they still want to do it, and feeling like a nag 18:30:27 similar to needs_info in PRs/issues :) 18:31:03 sometimes things are waiting for something, but then after some time that something happens, but folks forgot about the thing that was waiting for it 18:31:11 there a reminder would be very helpful 18:31:19 not sure, if it's worth time investment in a long term perspective:) but we could try 18:32:08 anyway inventory of topics is needed imo, so i can create the view along the way 18:33:01 It's always worth trying out things. But it's also important to stop if it turns out they don't work ;-) 18:34:08 or if they cost too much for too little gain, and the folks doing them aren't like "I still want to do it because it's soooo much fun!" :) 18:35:47 if we keep things updated, it'd be easier to find them but a good question is what is less energy/time consuming updating things each time or going through all the topic once in several months 18:36:52 if there's a habit to add topics to the board (not every topic needs to be implemented), maybe it won't be very time consuming 18:37:24 overall 18:38:12 ok, i'll take a look 18:38:49 does anyone have anything else to discuss? 18:38:51 :) 18:39:08 yes: https://github.com/ansible-community/community-topics/issues/123 - this is about a PR https://github.com/ansible-collections/overview/pull/212 18:39:25 since I haven't received further feedback on it, I'll probably start a vote on the PR 18:39:35 so if anyone wants to do more wordsmithing on it, please take a look now :) 18:39:44 FTR, I'm +1 18:39:54 it's improving one inclusion rule on licensing 18:40:21 basically the original wording was talking about files in plugins/, but the way it was written it also covered files outside plugins/ 18:40:28 the PR should fix that 18:42:04 another topic we can talk about is https://github.com/ansible-community/community-topics/issues/124 - remove servicenow.servicenow in Ansible 8 18:42:22 or even Ansible 7 18:42:52 I think we should do that (I think we should wait for 8 since we didn't already deprecate it in 6.0.0, but I can also live with 7) 18:43:04 Is the new collection mostly compatible with the old one (besides the name change)? 18:43:29 Yep. Wanted to mention this, anyway. Just didn't want to interrupt the ongoing discussions :-) 18:44:00 I'd also like to discuss https://github.com/ansible-community/community-topics/issues/126 18:44:30 Is anything about the new collection really important? The old one isn't maintained anymore... 18:45:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:45:15 mariolenz[m]: I don't know either of the collections 18:45:30 I suppose that's true. It would be nice if we provide information about migrating in the porting guide, though. 18:45:30 though I guess they are not really compatible to each other, otherwise there would have been no reason to start with a new one rom scratch 18:45:50 Do we want to involve the maintainers here? 18:46:27 I think dmsimard (or someone else?) already contacted them in the past, but I don't know what the outcome was 18:47:25 Do we have a workflow to remove collections that are deprecated? I know there is one for collections we consider unmaintained, but what about the case if the collection maintainers announce they'lss stop maintaining it? 18:47:54 I don't think we have a workflow for that yet 18:47:55 It looks like it's been deprecated for almost a year, so I guess it does make sense to remove it sonner. 18:48:10 I guess it would be a subset of the unmaintained one, basically announce that it is deprecate, and remove it in 1-2 releases 18:50:17 I think it's OK to wait until Ansible 8 if we consider a collection unmaintained, but if the collection itself announces that it's deprecated / unmaintained...? I really think we should remove it from Ansible 7. 18:50:57 I think in the future we should still make sure that there is at least one full release cycle between deprecation and removal, but I guess here it's ok since it already was marked as deprecated quite some time ago (at least in the repo) 18:51:07 So not remove it in 2, but in the next (major) release. 18:51:10 it would have been nice if they would have made a new release which says that it is deprecated... 18:51:14 Ansible 6 was released a month ago, so imo no need to wait until 8 (almost a year, right?) 18:52:04 does someone want to create a PR to announce deprecation and removal from Ansible 7 in the Ansible 6 changelog? then we can do a quick vote on it (i.e. one week) 18:53:12 also if someone wants to formulate a procedure for removing deprecated collections that does not require a vote for each of them in https://github.com/ansible-collections/overview/blob/main/removal_from_ansible.rst, that would be great. then we can vote on the procedure and in the future remove without further votes. 18:53:15 OK, should I just add a deprecation for this collection that we'll remove it from Ansible 7 or should I first open a vote on this? 18:53:43 mariolenz[m]: I think creating both at the same time is fine, we can then merge the deprecation once the vote is accepted 18:53:48 +1 18:54:07 i don't think there will be a wide opposition:) 18:55:01 OK, I'll do. 18:55:26 mariolenz[m]: thanks! 18:56:40 Does anyone have anything to say about my issue :)? 18:56:41 https://github.com/ansible-community/community-topics/issues/126 18:57:26 gotmax (He/Him): I remember that RH legal has gotten involved in questions about compliance with the GPL in the past 18:57:51 The issue feels pretty cut and dry to me, but okay 18:58:04 i'll try to take a look tomorrow 18:58:14 Felix said that someone reached out to them a while ago 18:58:15 and I gather the experience was memorable - I have no idea if they would object today, or even have an opinion 18:58:25 or how to find out 18:58:33 I know there have been several attempts to get more information from RH legal about such matters, but I don't know what exactly was asked or whether there has been any reply 18:59:07 that all went through the community team 18:59:24 we could, I suppose, take this as an opportunity to ask forgiveness instead of permission . . . 18:59:45 Honestly, the perceived issues don't really make sense to me. The artifact is not source code. 19:00:14 And I agree with the Linux distribution point. 19:00:20 gotmax[m]: I don't remember the exact reasons that were named by the folks who knew a lot more about this, so maybe I'm just reproducing something incompletely, or wrongly 19:00:32 Both Fedora and RHEL and CentOS Stream distribute GPL binaries. 19:01:01 acozine: Good with me ;) 19:01:20 Would it be possible to talk directly to legal? 19:02:08 Anyway, time's up. As a kind of homework for you: Is https://github.com/ansible-community/community-topics/issues/105 still open because / being implemented because Anisble 8 isn't released yet, or is it resolved because the removal of google.cloud has been announced for the Ansible 8 release? 19:02:56 Well, should be kept open for the one reason or should be closed for the other, I mean. 19:03:02 mariolenz[m]: it's open since the collection hasn't been removed from 8/ansible.in yet - after all that file doesn't exist yet 19:03:25 also folks can still start discussing new maintainers in there 19:03:47 I think it makes sense to keep it open until at least 8.0.0-a1, or even 8.0.0-b1 (feature freeze) 19:04:37 i could try to contact legal but we need to have a list of questions as complete as possible before asking 19:04:39 mariolenz: I wouldn't know how to try contacting RH legal 19:05:19 ok, folks, i'll add it to my todo and will take a look later, see you all 19:05:27 thanks everyone! 19:05:30 andersson007_: thanks 19:05:37 * acozine waves 19:05:37 andersson007_: I think it's best to first find out what kind of contact already happened in the past 19:05:44 thanks everyone! 19:05:52 #endmeeting