19:00:34 #startmeeting Ansible Community Meeting 19:00:34 Meeting started Wed Jan 6 19:00:34 2021 UTC. 19:00:34 This meeting is logged and archived in a public location. 19:00:34 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:34 The meeting name has been set to 'ansible_community_meeting' 19:00:34 #topic Agenda https://github.com/ansible/community/issues/539#issuecomment-755239495 19:00:37 abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping! 19:00:42 o/ 19:00:47 #chair cybette 19:00:47 Current chairs: cybette felixfontein 19:00:51 heyo! 19:00:53 #topic Updates 19:00:54 #info Ansible 2.10.5 has been released 19:00:54 #info community.google, community.hashi_vault, community.kubevirt and cisco.nso have been added to Ansible 2.10.5, they contain migrated content from community.general and community.network. Coming up next is community.fortios. 19:00:57 #info community.general 2.0.0 will be dependency free, and community.network 2.0.0 will only depend on ansible.netcommon once community.fortios is done. 19:01:00 #info The Bullhorn 17 has been released: https://mailchi.mp/redhat/the-bullhorn-17 19:01:01 \o/ 19:01:03 #chair geerlingguy 19:01:03 Current chairs: cybette felixfontein geerlingguy 19:01:08 #chair ompragash 19:01:08 Current chairs: cybette felixfontein geerlingguy ompragash 19:01:09 o/ 19:01:13 Hello! 19:01:13 #chair samccann 19:01:13 Current chairs: cybette felixfontein geerlingguy ompragash samccann 19:01:17 Greeting 19:01:20 * dericcrago waves 19:01:23 #chair lmodemal abadger1999 dericcrago 19:01:23 Current chairs: abadger1999 cybette dericcrago felixfontein geerlingguy lmodemal ompragash samccann 19:01:57 \o 19:02:00 #chair dmsimard 19:02:00 Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein geerlingguy lmodemal ompragash samccann 19:02:27 o/ 19:02:45 #chair tadeboro 19:02:45 Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein geerlingguy lmodemal ompragash samccann tadeboro 19:03:01 sorry for spamming the channel ;) 19:03:15 lol 19:03:25 just rearranging the deck chairs 19:03:33 * gundalow waves 19:03:35 it's great to see many people attending! musical chairs :D 19:03:46 hahaha 19:03:47 #chair gundalow 19:03:47 Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein geerlingguy gundalow lmodemal ompragash samccann tadeboro 19:04:00 luckily we have an infinite amount of chairs ;) 19:04:10 *empty 19:04:35 wangbaoshan: are you around? 19:05:00 yes 19:05:04 cool :) 19:05:05 #chair wangbaoshan 19:05:05 Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein geerlingguy gundalow lmodemal ompragash samccann tadeboro wangbaoshan 19:05:22 let's start with your topic then 19:05:35 (assuming there are no more announcements / general updates) 19:05:50 gundalow has an update in the agenda 19:05:55 I do 19:06:02 "pray he does not update it further" 19:06:16 heh 19:06:26 right 19:06:32 let's do gundalow's update then wangbaoshan 's topic 19:06:38 +1 19:06:41 gundalow: please start :) 19:06:48 #info very happy to welcome ompragash to the Ansible Community Engineering Team 19:06:55 welcome ompragash! 19:06:57 \o/ 19:07:00 cheers ompragash ! 19:07:08 Hi ompragash! 19:07:13 \o/ 19:07:18 #chair gwmngilfen 19:07:18 Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen lmodemal ompragash samccann tadeboro wangbaoshan 19:07:19 yay ompragash! 19:07:20 ompragash: Would you like to say hi (where in the world, and where people may know you from) 19:07:27 Super excited to join you guys!! :D 19:07:53 So I am from Chennai, India 19:07:54 felixfontein: I'm not here really ;) 19:08:08 gwmngilfen: want to be unchaired? ;) 19:08:17 gwmngilfen: Well, not you are ;) 19:08:19 ompragash: it must be pretty late / early for you 19:08:21 *now 19:08:41 #comfycushion gwmngilfen 19:08:41 it's mid night for me :P like 12:35 AM 19:08:46 ooch 19:08:56 OH my gosh 19:09:02 but don wanna miss my first meeting 19:09:13 ;) 19:09:22 You may know ompragash from the Indian Ansible Meetups. Previously he worked as part of the Ansible Support team 19:09:27 Midnight to 2am is totally my most productive timeslot :p 19:09:41 Gwmngilfen: ditto 19:09:44 ompragash: Thanks for staying up, see you tomorrow 19:10:05 Nice to meet you ompragash 19:10:09 the good thing is that there are logs :) 19:10:16 cool! later guys! meet you all very soon 19:10:20 (which is sometimes a lot more efficient than being in the meeting :D ) 19:10:27 ompragash: good night! :) 19:10:44 I guess we should move the meeting to an ealier timeslot eventually 19:10:51 ok. 19:11:02 we are 10 minutes into Updates 19:11:07 * cybette is trying to keep time today 19:11:09 It's 3:00 a.m. here 19:11:09 #topic inclusion of inspur.sm in Ansible 3.0.0 19:11:18 cybette: Thank you for doing timings :) 19:11:19 wangbaoshan: ok, that's even more extreme! 19:11:26 hey folks, in other meetings, so half here... 19:11:32 wangbaoshan: it's your topic now! 19:11:37 #chair briantist 19:11:37 Current chairs: abadger1999 briantist cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen lmodemal ompragash samccann tadeboro wangbaoshan 19:11:52 #link https://github.com/ansible-collections/ansible-inclusion/discussions/8 19:11:55 ok 19:11:59 #info We are using https://github.com/ansible-collections/ansible-inclusion/discussions to track requests for inclusion in `ansible` package 19:12:57 We made inspur.sm, which wants to add to Ansible 3.0.0 19:13:23 wangbaoshan: Firstly thank you for the collection and raising the requests 19:13:28 Excellent. 19:13:39 Is there any kind of CI for the collection? (Just glancing at it now, didn't see a link to it) 19:13:44 Now I need your help to check whether there is any problem 19:14:01 geerlingguy: GHA for `ansible-test sanity` https://github.com/ISIB-Group/inspur.sm/blob/main/.github/workflows/ansible-test.yml 19:14:20 geerlingguy: oh, are you meaning no badge link in README.md? 19:14:36 ah, lol I guess I could've just clicked the Actions tab and checked there 19:14:43 ah, CI only runs for PRs, not for pushes / commits in main 19:15:02 usually there's a green checkmark next to the latest commit as an indicator that there's some kind of CI :) 19:15:09 ah, so the scheduled job needs adding 19:15:37 wangbaoshan: DO you have any specific problems or are just waiting for review of the collection? 19:15:44 gundalow: that too, but also `push:` in `on:` 19:16:02 o/ 19:16:06 #chair acozine 19:16:06 Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen lmodemal ompragash samccann tadeboro wangbaoshan 19:16:07 sorry I'm late 19:16:18 acozine: :) 19:16:21 I'm waiting for approval. 19:16:47 we will discuss today of how we start (or at least I planned that for today's discussion) 19:17:06 so hopefully in the next days, or beginning of next week, we will actually start with the review process 19:17:18 I think reviews will start soon(ish), but there are a few thins that need to be sorted first IIRC. 19:17:21 (assuming there are no other plans which contradict this) 19:17:31 nod 19:17:50 tadeboro: anything else besides collection requirements? 19:18:20 I only had "approve the checklist" in mind. 19:18:43 tadeboro: ah, sounds good too :) 19:18:48 But maybe that thing is already finalized and I am not up-to-speed ;) 19:19:10 tadeboro: I think abadger1999 and/or gundalow need to study it more closely to see whether it doesn't contain surprises or is missing something important 19:20:01 wangbaoshan: ok, so I hope it's ok for you if we change topic and start discussing some things to get the review process started :) 19:20:11 We cold probably go off of the checklist and add things if they're missing later. I haven't stared at it closely yet, though, to make sure that it matches up with the full guidelines page. 19:20:19 ok 19:20:47 abadger1999: should we talk about collection requirements first, or about the review process / checklist / ...? 19:21:15 Is ther ea chance to approve the checklist quickly? If so, lets do that. 19:21:40 #topic collection checklist template https://github.com/ansible-collections/overview/issues/140 19:21:42 If not, collection requirements would be good to discuss and get thinking about sooner rather than later 19:21:51 I don't know if this goes quickly 19:21:58 but let's see :) 19:22:11 #info andersson007_ prepared a checklist for the collection requirements in https://github.com/ansible-collections/overview/issues/140 19:23:01 since we can't edit it in parallel, I suggest that if you want changes, propose them here. if we agree on them, I will edit the post 19:23:16 The idea is that this is a short view of the full collection guidelines, right? Someone can approve a new collection by going down the list and checking all the boxes? 19:23:22 my idea would be to convert it to a .md file in the repository if we approve it 19:23:27 abadger1999: yes 19:23:35 I did go through it and found that it reflects the things from the requirements document. 19:23:44 abadger1999: it also allows to see which topics have already been checked by other people 19:24:16 tadeboro: Thank you for using it. Did you find it helpful 19:24:29 it doesn't contain some 'soft' things that cannot be checked in a review (like 'keeping informed'), but IMO that's fine 19:24:39 Cool. I think I'd vote to approve if tadeboro and felixfontein have looked it over and found it agrees with the guidelines. 19:24:49 this is the minimum a collection must do to be considered for inclusion, correct? 19:25:01 it looks good to me 19:25:28 the only thing I think is missing is `- [ ] adheres to semantic versioning` :) 19:25:49 I created my own list when preparing sensu.sensu_go and the fact that my list and andersson007_'s list contained 90% of the same stuff gave me some confidence in my sanity. 19:25:50 as we noticed yesterday, some collections tend to violate that :) 19:25:52 I see this as "checklist to help Collection owner", rather than something for the inclusion-review 19:26:18 ah yep. We should probably add that more expluicitly to the longer collection guidelines too. 19:26:34 gundalow: hmmm... what would be the difference? 19:27:01 does anyone mind if I add `- [ ] adheres to [semantic versioning](https://semver.org/)` to the top of the `Standards and documentation:` section? 19:27:16 felixfontein +1 19:27:22 gundalow: I'd also use it during review. it makes it easier to not forget to look at certain aspects 19:27:23 abadger1999: I think collection inclusion review needs to be more than "I see lots of checkmarks, I'll add to `ansible.in`" 19:27:38 gundalow: it definitely is! 19:28:11 felixfontein: +1 to adding adheres to semantic versioning 19:28:22 felixfontein: I think it's good. Do we need to make that more clear in the main document as well? 19:28:25 felixfontein: yup, please could you add that 19:28:32 we were actually discussing semver for collections yesterday 19:28:32 I would hope there is no big difference between the list and the review requirements. Otherwise we might end up rejecting something that has all clear in that list, which si not the best experience for the collection amintainer. 19:28:46 it's happened twice that we got collections with breaking changes in minor revisions 19:28:54 tadeboro: +1 19:29:02 abadger1999: the main document mentions it, but it could definitely be more obvious 19:29:32 I've added the part with semantic versioning to the checklist 19:29:37 +1 19:29:41 hum, have we now ended up with two checklists that need to be in sync? 19:29:45 Yeah. so I think it's okay to add to the checklist now but maybe the wording i nthe main document needs to be updated too. 19:30:05 gundalow: one checklist is tadeboro's personal checklist which isn't public 19:30:07 does someone have a link to 'the main document'? 19:30:16 #info the main document: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst 19:30:29 thanks :-) 19:30:52 gundalow: I do think there's room for judgements to be made. But I agree heavily with tadeboro.... I'd see it like... if a judgement is being made that's not in the checklist/expanded review document, then we need to propose the new criteria here, approve it, and get it added to both places. 19:30:53 felixfontein: sorry, I meant `collection_requirements.rst` and https://github.com/ansible-collections/overview/issues/140 19:30:54 about the main document: how about adding `Collections MUST adhere to [semantic versioning](https://semver.org/).` as the first paragraph in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#versioning-and-deprecation ? 19:31:11 gundalow: ah. andersson007_ compiled the checklist to make it easier to review collections 19:31:15 gundalow: This is my list I talked about. Totally unofficial but derived from the same sources as the official one. 19:31:27 we're 10 minutes into "collection checklist template" (and 30min in the meeting) with 3 more topics to go 19:31:36 cybette++ 19:31:46 One thing I'm thinking about in terms of inspur.sm — it's a very large batch of modules (~130?)... do we have any guidelines in terms of keeping the overall size of ansible itself down over time? 19:31:47 VOTE: how about adding `Collections MUST adhere to [semantic versioning](https://semver.org/).` as the first paragraph in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#versioning-and-deprecation ? 19:31:54 +1 19:31:55 +1 19:31:55 +1 19:32:03 +1 19:32:03 +1 19:32:04 +1 19:32:11 +1 19:32:15 I guess my question above would be more along the lines of how do we deprecate unmaintained collections 19:32:27 geerlingguy: not as far as I know. I think the idea is to first see what happens for 3.0.0, and then to adjust the rules for 4.0.0 if we see how things go :) 19:32:36 gundalow: yes-ish.... They should say the same things but one should be concise and easy to read at a glance. The other should contain more information, examples, and other things that explain the spirit, intent, and history of the rule, not just what the rule is. 19:32:39 _1 19:32:42 +1 19:32:49 +1 19:33:27 abadger1999: OK, maybe in the future we can look at combing. No one else seems to have issue so I'll shut up :) 19:33:35 #agreed add `Collections MUST adhere to [semantic versioning](https://semver.org/).` as the first paragraph in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#versioning-and-deprecation 19:33:40 abadger1999: still seems a risk that it all gets out of sync. What about the checklist and the longer details both in the same document? 19:34:01 Using the original rst document as a checklist is not the nicest thing ever. Maybe they should just live in one document? 19:34:05 ok. should we vote on the checklist already, or first talk about collection requirements? we probably need to add something on requirements to the checklist when we decide to add it to the requirements document 19:34:07 abadger1999: so the 'top section' of that document is the checklist, and the rest of that same document is all the details (links back n forth if necessary) 19:34:51 samccann: Sort of -1 to that...... I think in a few years, the main document will be spread over multiple pages/fles. 19:35:18 also I don't know how hard it is to do checkmarks in RST :) 19:35:19 I agree about the synchronization, it would be nice if we could generate one from the other 19:35:24 tadeboro: yup, though I think we maintain two for the moment and see how people get on 19:35:27 abadger1999 ah gotcha. 19:35:58 #info https://github.com/ansible-collections/overview/pull/146 contains the changes to the requirements document we decide on today 19:35:58 https://github.com/ansible-collections/overview/pull/146 | open, created 2021-01-06T19:35:38Z by felixfontein: Extend collection requirements 19:35:59 have both docs versioned and synced via version number? 19:36:02 (so far only one) 19:36:28 I like the problem you're pointing out and that you're looking for a solution. I just think the solution is going to have to account for the scaling issues we're going to run into within a few years. 19:36:29 dericcrago: would be nice indeed, but let's do that as a second step, and in particular not today :) 19:36:30 I think we maybe drifting a bit 19:36:50 yes. 19:37:00 good morning ! 19:37:02 let's switch to collection requirements. if you disagree, complain NOW or shut up ;) 19:37:06 #chair russoz 19:37:06 Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen lmodemal ompragash russoz samccann tadeboro wangbaoshan 19:37:10 good morning russoz! 19:37:34 #topic collection requirements 19:37:42 dericcrago: That's an idea... maybe if we had some sort of document that had the succinct version and then the larger information in a certain format, we could automate that. 19:37:50 #info summary of the problem: https://github.com/ansible/community/issues/539#issuecomment-750301681 19:38:28 very short form: we need to make sure that collections do not add requirements that a) are not part of Ansible, and b) that do not make it impossible to build Ansible because of conflicting requirements (this will be incompatible version ranges) 19:38:51 I put up two possible rules in https://github.com/ansible/community/issues/539#issuecomment-755239495 19:38:59 ideas, comments, other suggestions are welcome! 19:40:15 so basically, ansible.netcommon added ansible.utils as a dependency, but it's not in Ansible so things break until ansible.utils becomes part of Ansible? 19:40:17 I agree that this is something that needs adding 19:40:23 * samccann works better w/ concrete example 19:40:25 samccann: exactly 19:40:39 samccann: yes. if we decide to not include ansible.utils in Ansible 3.0.0, we have to restrict ansible.netcommon to <2.0.0 19:41:08 sounds like something we need to have visible to developers before they think of making such a split, yeah. 19:41:17 samccann: and manually zookeeping such restrictions is not fun, so let's force collections to behave instead of us having to live with the pain 19:41:46 agreed 19:42:21 I don't think I like the way those two rules are phrased; possibly the direction that they take us in. I would like something in the spirit of "Everything in ansible must be usable without additional collections, outside of Ansible, being installed" 19:42:42 so walking through that same scenario - if say ansible.utils didn't make it into 3.0.0, the ansible.netcommon community could bring it into ansible.netcommon for 3.0.0, and then move it to its own collection (approved) in say Ansible 4.0.0? 19:43:01 abadger1999: I hacked the two rules together at the end of my lunch break, they can definitely be improved ;) 19:43:06 19:43:07 abadger1999: maybe needs the world `collection` adding? (ie we don't include Python dependencies) 19:44:21 samccann: theoretically yes, though I'm not sure they will like that. 19:45:01 I like abadger1999's version 19:45:58 felixfontein - yeah just want to understand what the workaround is if we hit this problem 19:45:59 basically we are killing collections' dependencies across the "already-included-in-ansible" border, is that it? 19:46:02 what do you think of using it together with " 19:46:02 If you plan to split up your collection, this must be discussed at and cleared by the community meeting first. 19:46:05 If you plan to add other collections as dependencies, they must run through the formal application process."? 19:46:34 also depeends on why ansible.utils was rejected. If it violated some collection rule and that wasn't addressed simply by including it in ansible.netcommon, then that wouldn't be a good solution. 19:46:54 russoz: kind of, we want that Ansible comes with all (collection) dependencies for content it includes, but we don't want a loophole where collections can include random other collections into Ansible by depending on them :) 19:47:15 "Collections in Ansible can only depend on other collections within Ansible." ? 19:47:24 we're 10 minutes into "collection requirements" (and 47min in the meeting) with 2 more topics to go 19:47:25 and then the followos 19:47:41 cybette++ for time keeping! it really helps 19:47:47 indeed :) 19:47:51 How about "If your collection depends on outside resources, those resources must be included in the Ansible package." 19:47:53 I think I'd change "If you plan to split up your collection, this must be discussed at and cleared by the community meeting first." somehow... Maybe "If you plan to split up your collection, the new collection must be approved for inclusion before the smaller collection is updated in ansible" 19:48:15 abadger1999: sounds good to me 19:48:58 LGTM 19:49:29 samccann: that's a bit too general, since it would also cover Python dependencies 19:50:14 https://github.com/ansible-collections/overview/pull/146#issuecomment-755591187 19:50:16 as in a collection can't depend on a Python version that is not what Ansible the package uses? 19:50:30 I've put the current sentences together, is that how you think it should be? 19:50:55 samccann: no, as in Ansible will not include Python dependencies that collections use, like Azure libraries, boto (AWS) libraries, etc. 19:50:55 for me, the 'outside resources' suggests things that might need to be installed that have nothing to do with Ansible. 19:51:27 felixfontein: - yeah the new sentence suggest to me that I couldn't have a collection that depended on Azure libraries 19:51:28 ah crap. sorry. I meant acozine's suggestion, not samccann's suggestion 19:51:34 sorry :( 19:51:46 ah, gotcha 19:52:09 > The `ansible` package MUST NOT depend on collections not shipped in the package. 19:52:11 what did i miss? 19:52:23 gundalow +1 19:52:32 that sentence seems clear to me 19:52:36 yeah, I like gundalow's phrasing 19:52:37 I fixed the first sentence in https://github.com/ansible-collections/overview/pull/146#issuecomment-755591187 to what I actually wanted it to be 19:52:46 #chair jtanner 19:52:46 Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen jtanner lmodemal ompragash russoz samccann tadeboro wangbaoshan 19:53:02 Those three additions look good to me. 19:53:14 I would vote +1 to adding them. 19:53:30 871197 19:53:31 I find gundalow's suggestion clearer than the new first sentence, but not gonna cry a river of tears if we keep what's there 19:53:38 oops sorry that's nothing to do with timing 19:53:51 btw, should we add it at the end of https://github.com/ansible-collections/overview/blob/79f33f9f227fbdf59fa9641dc1a9c42d66c2e0f1/collection_requirements.rst#galaxyyml ? 19:54:11 I can get behind gundalow's suggested wording for the first bullet point too. 19:54:30 both are fine for me 19:54:55 VOTE: `The `ansible` package MUST NOT depend on collections not shipped in the package` (a) or `Everything in ansible must be usable without additional collections, outside of Ansible, being installed.` (b) as the first sentence? 19:55:01 #chair 19:55:01 Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen jtanner lmodemal ompragash russoz samccann tadeboro wangbaoshan 19:55:04 I also like gundalow's phrasing better 19:55:13 a 19:55:15 (a) 19:55:15 a 19:55:27 a 19:55:30 a 19:55:42 a 19:55:44 a 19:55:45 ok, looks like a) :) 19:55:46 a 19:55:50 a 19:55:51 a 19:55:56 a 19:55:59 #agreed `The `ansible` package MUST NOT depend on collections not shipped in the package` as the first sentence 19:56:12 should we vote on https://github.com/ansible-collections/overview/pull/146#issuecomment-755591187 (current version)? 19:56:18 "If you plan to split up your collection, the new collection must be approved for inclusion before the smaller collection is updated in ansible" --> "If you plan to split up your collection, the new collection must be approved for inclusion before the smaller collections replace the larger in ansible" 19:56:38 or something to that effect 19:56:44 +1 for jtanner's improved wording 19:57:04 +1 19:57:15 +1 19:57:29 we're 20 minutes into "collection requirements" (and 57min in the meeting) with 2 more topics to go. 19:57:38 VOTE change second sentence to `If you plan to split up your collection, the new collection must be approved for inclusion before the smaller collections replace the larger in ansible.` 19:57:42 +1 19:57:42 (already 3+) 19:57:44 yes please? 19:57:45 +1 19:58:07 otherwise, the rest of the wording makes sense to me 19:58:10 #agreed change second sentence to `If you plan to split up your collection, the new collection must be approved for inclusion before the smaller collections replace the larger in ansible.` 19:58:11 +1 19:58:29 ok, let's vote on the latest version of https://github.com/ansible-collections/overview/pull/146#issuecomment-755591187 then, if nobody disagrees in the next 30 seconds or so :) 19:58:39 * jtanner is bad at voting =( 19:59:15 VOTE: add https://github.com/ansible-collections/overview/pull/146#issuecomment-755591187 at the end of https://github.com/ansible-collections/overview/blob/79f33f9f227fbdf59fa9641dc1a9c42d66c2e0f1/collection_requirements.rst#galaxyyml ? 19:59:41 +1 19:59:43 * tadeboro likes votes with +/- options because he can use large + button in the numpad area of the keyboard ;) 19:59:45 +1 19:59:49 +1 19:59:52 +1 19:59:58 +1 19:59:58 +1 19:59:58 +1 20:00:00 +1 20:00:01 +1 20:00:04 +1 20:00:05 sheepit 20:00:13 +1 20:00:55 jtanner: baah baah :) 20:01:10 one hour into the meeting! 20:01:17 #agreed add https://github.com/ansible-collections/overview/pull/146#issuecomment-755591187 at the end of https://github.com/ansible-collections/overview/blob/79f33f9f227fbdf59fa9641dc1a9c42d66c2e0f1/collection_requirements.rst#galaxyyml ? 20:01:33 #info https://github.com/ansible-collections/overview/pull/146 contains both changes 20:01:57 should we vote on merging the PR, or does anyone thinks more needs to be added? 20:02:23 merge it 20:02:27 merge 20:02:33 merge it. 20:02:37 +1 merge 20:02:38 smash the big green button! 20:02:39 like i said, sheep it. 20:02:49 VOTE: merge? 20:02:51 +1 20:02:51 like he said, sheep it 20:02:55 +1 20:02:59 +1 20:03:01 +1 20:03:12 +1 20:03:21 all these sheep counting making me sleepy 20:03:51 +1 20:03:57 +1 20:03:59 The second half of the issue is about versioned deps. I'm not sure if we'll be able to approve that today but we should discuss it too. Maybe ten minutes of discussion and then move on (planning to revise and vote on it next week)? 20:04:16 ok 10 min timebox 20:04:35 it would probably also be good to get the checklist approved 20:04:47 #agreed merge https://github.com/ansible-collections/overview/pull/146 20:05:02 should we replace `- [ ] collection dependencies are stable, hence are set to '>=1.0.0'` by `- [ ] collection dependencies are stable, hence are set to '>=1.0.0', and are all part of Ansible`? 20:05:11 (in the checklist https://github.com/ansible-collections/overview/issues/140) 20:05:28 can we remove `stable`? 20:05:51 (cybette okay, this is a different discussion than I was thinking of) 20:05:54 fine for me 20:06:11 abadger1999: cybette: sorry, I think it's easier to start the review process if the checklist is approved :) 20:06:18 >- [ ] collection dependencies are all set to '>=1.0.0', and are all part of the `ansible` package? 20:06:18 Yeah 20:06:20 I agree that >= 1.0.0 is enough since this is stable by semver 20:06:23 nod 20:06:38 gundalow: +1 20:06:40 do the contributers have a definition of what "stable" means? 20:06:46 gundalow: +1 20:06:53 jtanner: that's why it says `>= 1.0.0` directly after it ;) 20:07:02 jtanner: They need to follow semver. 20:07:04 hah, okay but that tells me nothing =P 20:07:12 more suggestions, or should we vote on gundalow's suggestion? 20:07:30 +1 on gundalow's suggestion. 20:07:38 +1 20:07:51 Are we really talking about dependencies here or the collections themselves? 20:07:51 VOTE: Should we replace `- [ ] collection dependencies are stable, hence are set to '>=1.0.0'` by `- [ ] collection dependencies are all set to '>=1.0.0', and are all part of the `ansible` package` in the checklist? 20:07:58 abadger1999: collection dependencies. 20:07:59 +1 20:08:00 i guess i should have asked "do the contributes have information on the 'philosophy' of 'stable' according to semver" 20:08:06 +1 20:08:11 +1 20:08:11 Is collection deps in the main guidelines 20:08:29 oh, so it is 20:08:30 abadger1999: it is, see https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#galaxy-yml 20:09:15 hmm, maybe "all set to '>=1.0.0'" is not a good formulation, since sometimes you want `'>=2.0.0'` etc. 20:09:36 and tightly coupled collection pairs such as amazon.aws and community.aws might also have more specific requirements 20:09:37 felixfontein: ah, good call 20:09:46 do we need an upper bound, like '>=1.0.0,<2.0.0'? 20:10:16 dericcrago: upper bounds will bite us when one collection didn't update their bound the dependency has a new major release we want to include :) 20:10:18 Interesting; I thought version 1.0.0 was for things in ansible rather than deps. But I see it's only about deps now. 20:10:44 abadger1999: it is for both. collections should depend on stable dependencies, and be themselves stable 20:10:57 felixfontein - but by semver we'll automatically include breaking changes? 20:10:57 Approving "deps must be in ansible" does enforce 1.0.0 on some subset of collection in ansible now. 20:11:04 but I don't see that explicitly. 20:11:22 dericcrago: the problem happens with a new major version of Ansible 20:12:48 dericcrago: think that during the 3.0.0 release process, you suddenly find out that foo.bar wants community.general < 2.0.0 20:13:08 I think as long as you write it in words "Collection dependencies are greater than semver 1.0.0..." 20:13:09 The problem is one of coordination. If ten collections requires ansible.utils >= 1.0, <= 2.0 all ten of those collections will have to be updated when ansible.utils is updated to 2.0.5 in ansible. 20:13:23 so don't use the format of an actual dependency like >=1.0.0 20:13:24 urrrrrrrgh 20:13:54 samccann: `Collection dependencies must have a lower bound on the version which is at least 1.0.0`? 20:14:08 felixfontein - ok, when the first ansible major release (3.0.0) build is done, it will cap the upper bounds? 20:14:24 10 minutes into "collection dependencies in checklist" (74 min in meeting) 20:15:17 dericcrago: so you want to re-release all the offending collections with updated dependencies? 20:16:38 Note, we seem to be discussing both phrasing of one element in the checklist and a new/changed criteria for collection versions right now. 20:17:09 let's not touch the criteria, only the checklist 20:17:11 Do we want to finish the easier one (how to make the checklist wording reflect what's currently in the full guidelines) before moving on to the second one? 20:17:22 +1 on that 20:17:23 felixfontein - I'll table my discussion for now :) 20:17:39 (I don't really see a need to update the requirements though) 20:17:39 Cool, so the currnt guideline only talks about the lower bound of 1.0.0 20:18:19 felixfontein suggested: `Collection dependencies must have a lower bound on the version which is at least 1.0.0`? 20:18:28 hmmmmm, it explicitly says `>=1.0.0` there - I thought it would say "at least >=1.0.0" or something like that 20:18:59 >= implies "at least" 20:19:30 dmsimard: if the requirement must be `>=1.0.0`, you cannot require `>=2.0.0` 20:19:34 I would suggest NOT using the direct syntax that is used in the collection itself 20:19:39 ^ woah I didn't know quote formatting works here (or maybe it's my client) 20:19:45 use 'must be greater than or equal to" 20:19:51 briantist: it's your client :) 20:20:02 I agree with samccann here: just drop the >= 20:20:19 I like abadger1999 suggestion. 20:20:39 (It's really felixfontein's. I just requoted it to get us back on track :-) 20:20:56 should we replace it both in the checklist and the collection requirements? 20:21:09 felixfontein: Yes please 20:21:23 I would say yes, because we only want to enfore stable. 20:21:28 VOTE: in both the checklist and collection requirements, replace the part on >=1.0.0 with `Collection dependencies must have a lower bound on the version which is at least 1.0.0` 20:21:34 +1 20:21:35 +1 20:21:38 +1 20:21:40 +q 20:21:42 +1 20:21:47 +1 20:21:50 +1 20:21:56 +1 20:21:57 +1 20:22:14 +1 20:22:14 #agreed in both the checklist and collection requirements, replace the part on >=1.0.0 with `Collection dependencies must have a lower bound on the version which is at least 1.0.0` 20:22:34 then collections can also happily depend on ansible.netcommon >=2.0.0 :) 20:22:41 (once it's included in Ansible ;) ) 20:23:23 I've updated the checklist and https://github.com/ansible-collections/overview/pull/146 20:24:21 VOTE: replace `- [ ] collection dependencies must have a lower bound on the version which is at least 1.0.0` in the checklist by `- [ ] collection dependencies must have a lower bound on the version which is at least 1.0.0, and are all part of the `ansible` package` 20:24:33 then the checklist says the same as the requirements 20:24:43 #chair 20:24:43 Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen jtanner lmodemal ompragash russoz samccann tadeboro wangbaoshan 20:24:52 +1 20:24:57 Those could be two separate checklist items. 20:24:57 +1 20:24:59 +1 20:25:02 +1 20:25:03 +1 20:25:05 I'm +1 either as one item or separate 20:25:09 +1 20:25:13 +1 20:25:20 (I think it follows from our two previous votes ;-) 20:25:25 abadger1999: could be, but I guess they will usually be checked together anyway 20:25:27 20 minutes into "collection dependencies" (85 min in meeting). let's try to conclude this topic. 20:25:59 once the vote is complete, let's finally vote on the checklist 20:26:06 +1 20:26:13 +1 20:26:24 #agreed replace `- [ ] collection dependencies must have a lower bound on the version which is at least 1.0.0` in the checklist by `- [ ] collection dependencies must have a lower bound on the version which is at least 1.0.0, and are all part of the `ansible` package` 20:26:49 ok 20:26:54 I've updated the checklist 20:27:17 should we vote on accepting the checklist (everything until exluding `Removed from the list (if anybody disagrees, please tell us):` and the lines below)? 20:27:47 +1 (both for voting and for the checklist itself) 20:28:09 +1 from me in advance if the vote happens (need to go AFK for a bit) 20:28:24 VOTE: should we accept the checklist (everything until exluding `Removed from the list (if anybody disagrees, please tell us):` and the lines below)? 20:28:30 +1 20:28:33 +1 20:28:41 +1 20:28:49 +1 20:28:57 +1 20:28:58 +1 20:29:08 if it's ok for everyone (and we agree on the checklist), I would add it as a file collection_checklist.md in the repo (in the same PR https://github.com/ansible-collections/overview/pull/146) 20:29:08 https://github.com/ansible-collections/overview/pull/146) | open, created 2021-01-06T19:35:38Z by felixfontein: Extend collection requirements 20:29:19 felixfontein: +1 20:29:43 #agreed we accept the checklist (everything until exluding `Removed from the list (if anybody disagrees, please tell us):` and the lines below) 20:29:58 #info I've updated https://github.com/ansible-collections/overview/pull/146 20:30:14 it contains the checklist as collection_checklist.md, and the changes to the requirements 20:30:58 should we vote on merging the PR? or does anyone wants something changed? 20:31:28 I think since we've voted on the contents, we don't need to vote on the PR itsself. 20:31:42 Just move on to the next thing that requires our attention 20:31:44 agreed, merge 20:31:51 ok. 20:31:55 90 min of the meeting, 2 topics left "Modhelper improvements" and "Ansible 2.10 releases after 3.0.0" 20:32:03 abadger1999: gundalow: can you approve + merge? 20:32:07 will do 20:32:09 ok, what should we talk about next? 20:32:20 `Ansible 2.10 releases after 3.0.0`? 20:32:23 collection dependency versions, actually starting the review, ...? 20:32:32 or that :) 20:32:49 What ever we pick, should we end in 15 minutes? 20:32:56 sounds good 20:33:03 we're already at 1:32 h 20:33:38 abadger1999: is it ok if we discuss collection dependency versions next week? it probably helps to prepare something for that 20:33:51 (and if we're more 'fresh' :) ) 20:34:19 #topic starting the collection review process 20:34:59 how should we proceed with that? I'm not sure whether we're waiting for some formal start, or just that someone starts reviewing :) 20:35:29 is there a question we need to answer on this topic? 20:35:58 I don't really know 20:35:59 I think that might be on me to "volunteer" someone 20:36:03 felixfontein: yep 20:36:09 (from my team) 20:37:12 I think felixfontein, you and andersson007_ have been spearheading the review and approval of collection splits. So you're best to know if we're ready. But gundalow is going to volunteer someone from the team to drive it..... What role do you want to play? 20:37:20 Leader, trainer, advisor? 20:37:50 I'm happy to advise and review :) 20:38:02 (By the team to drive it... I mean, make sure that someone is going through the queue and everything reasonable gets looked at) 20:38:15 Cool :-) 20:38:45 so I thinking that myself plus dericcrago and/or dmsimard will go through the collections and checklists one-by-one adding feedback into the GitHub Discussion. No doubt while doing the reviews we will identify things that need fixing that aren't part of the checklist. So we will feed those new items into this meeting 20:39:05 I can help triage things, but would rather see someone else making the final decision. 20:39:05 20:39:19 tadeboro: I appreciate that, thank you 20:39:47 tadeboro: At some point, if this community project idea works, I hopoe you and others do feel good about making the final decisions :-) 20:41:31 abadger1999: This is more of a "I do not want my first major contribution to be approving collection that does not meet the standards" situation ;) 20:41:51 tadeboro: we'll blame you forever, and then some more!!!!!11 ;) 20:42:32 heh 20:42:32 I'll make you a t-shirt to commemorate it ;) 20:42:41 cybette++ 20:42:45 * samccann needs to be afk for a bit 20:43:00 ok, I guess then let's move to a quick open floor and then conclude this meeting? 20:43:05 #topic open floor 20:43:14 if you have something, talk up now. will close in two minutes. 20:43:34 tadeboro: oh, I'm totally OK to be the proxy things like that 20:44:05 for next meeting, it'll be great to add an approx time to the topic. we'll probably overrun it still, but good to have a reference and I'll try to enforce 20:44:32 cybette: sounds good! 20:44:39 adding a goal might help too 20:44:48 * felixfontein is still hoping that we eventually have less important and extensive topics :) 20:44:53 yep 20:45:09 yeah, once we tackle the big ones, it should get easier 20:45:24 though we already said that ... more than half a year ago? ;) 20:45:31 :D 20:45:34 heh 20:45:46 anyway, thanks everyone for this awesome meeting! 20:45:48 #endmeeting