18:00:11 #startmeeting Ansible Community Meeting 18:00:11 Meeting started Wed Aug 5 18:00:11 2020 UTC. 18:00:11 This meeting is logged and archived in a public location. 18:00:11 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:11 The meeting name has been set to 'ansible_community_meeting' 18:00:21 .hello2 18:00:21 so, who's around? 18:00:21 cyberpear: cyberpear 'James Cassell' 18:00:21 hi 18:00:33 #chair cyberpear andersson007_ 18:00:33 Current chairs: andersson007_ cyberpear felixfontein 18:00:48 abadger1999: acozine: samccann: gregdek: anyone else? 18:00:57 o/ 18:01:06 o/ 18:01:10 #chair samccann gregdek 18:01:10 Current chairs: andersson007_ cyberpear felixfontein gregdek samccann 18:01:11 Óla 18:01:14 (lurking) 18:01:18 #chair abadger1999 18:01:18 Current chairs: abadger1999 andersson007_ cyberpear felixfontein gregdek samccann 18:01:24 gregdek: that's also fine :) 18:02:01 #info agenda: https://github.com/ansible/community/issues/539#issuecomment-668229998 18:02:56 first part for today is getting everything ready for the announcements (issues in collection repos) for Ansible 2.10 18:03:38 there are three things left: 1) https://github.com/ansible-collections/overview/pull/94 2) announcement text (https://gist.github.com/felixfontein/65a86c4fe47e9c645eebadd52d8b0d5c) and 3) actually create the issues 18:04:55 any questions/comments so far? 18:05:18 3) do you need to do it once? next announcements will be delivered via the newsletter and issue 45, right ? 18:05:42 my opinion would be to do it once 18:05:49 ok 18:05:57 maybe we should add that to the announcement 18:05:58 I think 3) "create the issues" is to get confirmation from each collection maintainer that they understand the process/requirements 18:06:16 maybe have it be part of "onboarding" for new collections maintainers 18:06:22 nobody can claim "I didn't know" afterwards - except if they ignore issues in their own repo 18:06:48 +1 18:06:49 +1 to that idea 18:06:51 Good also to send to ansible-devel@ list to fill in the cracks 18:07:09 indeed! 18:07:16 +1 to that as well 18:07:21 yep 18:07:29 so maybe let's first look at the PR (and get it merged), and then finish the announcement text 18:07:42 hello 18:08:01 i've already done that felixfontein , looks good to me 18:08:02 sorry I'm late 18:08:24 #chair acozine 18:08:24 Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gregdek samccann 18:08:26 no problem! 18:08:41 andersson007_: I saw :) 18:08:53 does anyone else has comments for https://github.com/ansible-collections/overview/pull/94 ? 18:08:54 maybe somebody will find something interesting i missed 18:09:42 no real comments on the PR from me, but I would like to eventually move it into docs.ansible.com 'somewhere that makes sense' 18:10:05 +1 to that 18:10:12 or at least reference it if we think the rules should stay in the ansible-collections repo 18:10:24 samccann: true 18:10:41 94 looks good to me as-is 18:10:56 it's probably a good idea to revisit this when it is clearer what happens to ansible vs. ansible-base docsite(s) 18:11:35 ok, if nobody complains until in ~2 minutes, I'll merge 18:11:38 btw would be also nice to have a reference to ANsible Collections Checklist from the doc 18:11:40 Looks good to me 18:11:46 how does it render? does it need another blank line to divide the current lines 96 and 97? 18:12:12 acozine: I have no idea, since github doesn't want to render it for me :( 18:12:20 heh 18:12:23 https://github.com/ansible-collections/overview/blob/9d8caa4b6c6dc5c6d96244ddac63f7f7f0a07532/collection_requirements.rst is anyone more successful? 18:13:08 well, if the bulleted list is messed up when rendering comes back, we know what the issue is ;-) 18:13:10 I think it renders correctly but looks a little funny in the raw rst (since you do need the extra blank line when indenting further) 18:13:19 hello 18:13:31 the interesting thing is that https://github.com/ansible-collections/overview/blob/master/collection_requirements.rst renders for me 18:13:34 #chair baptistemm 18:13:34 Current chairs: abadger1999 acozine andersson007_ baptistemm cyberpear felixfontein gregdek samccann 18:13:37 (I just tested a simple list with rst2html) 18:13:43 i'm having the same rst problem 18:14:03 but my nickel is merge and we can fix it later if it needs more space 18:14:03 abadger1999: I was told that the blank line is needed, because otherwise the result is screwed up (at least on github) 18:14:26 Yep, you need the blank line when you indent furhter. 18:14:37 You do not seem to need an extra blank line when you outdent 18:14:44 excellent 18:14:50 also, TIL the word "outdent" 18:15:06 :-) 18:15:23 ok, then I'll merge :) 18:15:37 heh 18:16:02 ha! https://github.com/ansible-collections/overview/blob/master/collection_requirements.rst gets rendered 18:16:19 the list looks good on github: https://github.com/ansible-collections/overview/blob/master/collection_requirements.rst#versioning-and-deprecation 18:16:45 and there's only one TODO/FIXME left: `FIXME to write a guide "How to write CI tests" (from scratch / add to existing) and put the reference here` 18:16:53 (which I guess is OK for now) 18:17:16 #info https://github.com/ansible-collections/overview/pull/94 has been merged 18:17:34 #topic https://gist.github.com/felixfontein/65a86c4fe47e9c645eebadd52d8b0d5c 18:17:45 I started writing an announcement for collection issues: https://gist.github.com/felixfontein/65a86c4fe47e9c645eebadd52d8b0d5c 18:17:54 this probably needs some more polishing 18:19:30 andersson007_ suggested to drop the last part in brakets in the "Important date: 2020-08-18" section 18:19:32 felixfontein: I'm happy to polish, what's the best mechanism (since it isn't a PR)? 18:19:45 oh, comments. . . I can do that 18:19:49 acozine: good question 18:20:02 I can turn it into a repository with one file, then you can create PRs if you want 18:20:05 or use comments 18:20:10 depends on how much you want to change :) 18:20:19 so is this the issue to go into every repo to wake them up to what they need to do to get their collection in 2.10? 18:20:24 samccann: yes 18:20:40 ok then yeah a bit of wordsmithing would help it 18:20:57 when do you want it finished? 18:21:37 I think we should start creating the issues as soon as possible, so hopefully today :) 18:22:06 2020-08-18 is coming closer every day 18:22:20 that it is... that it is. 18:22:21 less than two weeks from now, actually 18:22:44 #info suggested edits to https://gist.github.com/felixfontein/65a86c4fe47e9c645eebadd52d8b0d5c needed TODAY if possible 18:22:45 I can take a look today 18:22:52 kewl 18:22:59 The issue template looks good to me. (I still hate that I need to separately subscribe to the Bullhorn, and my e-mail client hasn't found any mention of "bullhorn") 18:23:00 cool, thanks! 18:23:10 acozine: actually, when today? for me it's already evening :) 18:23:16 heh 18:23:26 well, I have this meeting, and then another meeting the next hour 18:23:31 but it's only one page 18:23:39 so in 2.5 hours I think I can have revisions for you 18:23:40 cyberpear: you can also subscribe to the issue where content for bullhorn is selected. and all important things are posted to the issue mentioned there anyway 18:24:00 fair enough 18:24:00 i would put in everywhere in `ansible_collections/*`myself. felixfontein: you could create this in c.g. then ping me 18:24:20 andersson007_: I can do that 18:24:20 in/it 18:24:28 felixfontein: cool:) 18:24:37 i'll use the script 18:24:46 ok 18:25:02 I'll collect a list of repos outside ansible_collections and try to add it to most of them 18:25:14 nice 18:25:18 acozine: do you prefer this to be a repo so you can create a PR? 18:25:29 felixfontein: that would make it quicker 18:25:44 well, quicker for me 18:25:47 maybe in `overview`? 18:25:48 and all: can you think of things that should be added, removed, or changed? (especially content-wise) 18:26:00 andersson007_: good idea, would save me yet another repo 18:26:08 yup 18:27:06 +1 to putting it in overview. we'll likely need something like this every release 18:27:17 every major release that is 18:27:56 samccann: though next time I guess we can use a shorter form, and simply publish it in https://github.com/ansible-collections/overview/issues/45 and bullhorn 18:28:13 creating an issue in every collection repo is somewhat tedious 18:28:30 #info announcement is here, create PRs if you want something changed: https://github.com/ansible-collections/overview/blob/master/tmp-announcement.md 18:28:31 true. 18:28:52 (and not all collections live on github) 18:29:36 ok, there's one thing in the announcement that I need your all's opinion on 18:30:11 the last sentence of the "Important date: 2020-08-18" section is `**If not, the same 0.x.y version will be used in all of Ansible 2.10 without updates,** and a 1.x.y will only be included in Ansible 2.11 (except if you can vouch for backwards compatibility with the included version, and then it's a manual process we really want to avoid).` 18:30:35 andersson007_ suggested to drop the part in brakets, to make it more likely people do not use that backdoor :) 18:30:41 as i mentioned this can relax our folks too much 18:30:42 I like the suggestion. what do you all think? 18:31:50 I agree, giving people an "out" up front is risky 18:32:20 I changed that section to `(unless you go through a demanding manual process to vouch for backwards compatibility . . . you want to avoid this!)` 18:32:28 but leaving it out altogether seems better 18:32:50 does anyone wants to leave it in its current or a modified (like acozine's suggestion) form? 18:33:21 i.e. anyone wants to discuss about this before we vote? 18:34:20 I think having the out mentined is more honest, though 18:34:51 I'm okay with it as is or in acozine's form. 18:35:03 abadger1999: that's fair 18:35:18 how many collections don't have a 1.x yet? 18:35:19 Trying to think if there's a third way. 18:35:43 are we talking about three potential collections going through this process? a dozen? a hundred? a thousand? 18:36:05 24 are <1.0.0, 48 are >=1.0.0 in alpha 7 18:36:11 could we get away with 'email foo' for questions? 18:36:31 that way anyone wanting a waiver or to prove backward compatibility has someone to talk to? 18:37:09 hope it won't become something typical once (the manual inclusion) 18:37:41 :) 18:37:46 I have been writing "Discuss in the community irc meeting" [this meeting] when I have to write who to talk to. 18:38:42 :) 18:39:13 that would be worth adding to the doc for sure (discuss on community irc meeting) 18:39:18 I rebuilt the build file, 22 collections are still <1.0.0 18:39:21 it's a solution, i think. but a bit more complicated would be better:) joking 18:39:26 I'm actually okay w/ acozine's wording as well 18:40:57 yep, I think it's good 18:41:09 * acozine is working on edits as we speak/type 18:41:14 something like meaning "in case of emergency, you need 1) register the topic about manual inclusion on aganda 2) discuss this on community irc meeting" 18:41:14 cool :) 18:41:18 I'd say don't drop it, but reword it however you want, even if it's "convince the community meeting unanimously that it's compatible" 18:43:04 that sounds like consensus 18:43:04 should we mention a precise process already (i.e. bring it up in community meeting), or simply keep the "demanding manual process"? 18:43:56 I like being specific about where to start the process. 18:44:00 agenda -> meeting -> demanding , imo, is good 18:44:46 POLL: 1) mention precise process (agenda -> meeting -> demanding), 2) only mention "demanding manual process", 3) drop it 18:44:59 +1 to needing to bring it here for discussion 18:45:02 we'll need time to look at such a repo, at least quickly, before meetings 18:45:08 1 18:45:11 3 18:45:17 1 or 3 18:45:33 1 18:45:41 1 or 3 18:45:55 1 18:46:06 how about `(unless you request an exception at a community working group meeting and go through a demanding manual process to vouch for backwards compatibility . . . you want to avoid this!)`? 18:46:06 perhaps adding is left to the reviewers 18:46:14 decision 18:46:15 it would have a link to the WG agenda 18:46:40 acozine: sounds good to me! 18:46:57 so we have 2 x 1, 2 x "1 or 3" 18:47:05 any more opinions? 18:47:28 1-ish, as detailed ^^^ 18:47:29 acozine: +1 18:47:41 Is that a vote for #1? 18:48:20 +1 for acozine's rewrite above 18:48:23 heh, I think my suggested wording is close to #1, but maybe not what everyone had in mind 18:48:40 works for #1 to me. shipit 18:49:32 andersson007_: baptistemm: is acozine's suggestion ok for you? 18:49:51 cyberpear: I guess acozine's suggestion fits what you wanted? :) 18:49:54 * baptistemm tries to merge the sentence 18:50:22 ok 18:50:26 ok 18:50:31 yes 18:51:05 great! 18:51:25 `go through a demanding manual process` sounds good:) 18:51:26 #agreed let's use acozine's suggestion: `(unless you request an exception at a community working group meeting and go through a demanding manual process to vouch for backwards compatibility . . . you want to avoid this!)` (with link) 18:51:49 intriguing, i'd say:) 18:52:45 ok great :) 18:52:56 then acozine is polishing the text, and andersson007_ and me will start distributing it as issues 18:53:08 +1 18:53:25 aw shucks, I missed most of the meeting today. Need to set a reminder as it's always around lunch time 18:53:42 #topic should we do a 1.1.0 release for c.g and c.n on 2020-08-18 (i.e. last date before freeze)? 18:54:00 (assuming there is new content, which is true for community.general, and probably true for community.network) 18:54:07 #chair geerlingguy 18:54:07 Current chairs: abadger1999 acozine andersson007_ baptistemm cyberpear felixfontein geerlingguy gregdek samccann 18:54:10 hi geerlingguy! 18:54:19 geerlingguy: don't worry. this one goes long 😋 18:54:27 * geerlingguy because we care 18:54:53 so, question in topic 18:55:00 felixfontein: when 1.0.0 was released? could you remind me please 18:55:16 I'm okay either way. 18:55:24 when we decided on the versioning plan for c.g and c.n, we said that 1.0.0 is released end of july (we released it on 31st), and release new minor versions every two months 18:55:36 with the exception of maybe releasing a new minor release in time for 2.10.0 18:55:41 s/exception/option/ 18:55:57 is there any chance someone will pull more content out of the 1.0.0 release and put it in a different collection? 18:56:03 or is that work frozen for now? 18:56:27 samccann: there's no such chance, next time something can be removed is 2.0.0 18:56:33 (IMO) 18:56:33 whew 18:57:01 is there any drawback to revving to 1.1.0 to include the most recent changes in ansible 2.10? 18:57:03 there are two topics on the agenda of discuss moving though (not sure whether we'll have time today though) 18:57:08 samccann: I don't think so 18:57:23 then i'm +1 for revving so the most recent is in 2.10.0 18:57:26 the main reason not to do it is "because we said every two months" 18:57:32 oh hah 18:57:52 which is a somewhat poor reason IMO :) 18:58:19 there are already some bugfixes and new plugins/modules, I think it would be nice to the contributors to get them into 2.10.0 18:58:32 abadger1999: have we Thunk Deep Thoughts about this - collection versions in alpha vs what is in the final release? I feel like this sort of decision will happen every major ansible release 18:58:39 (well, for c.n there's a new module in the make, it's not merged yet) 18:59:17 I guess in the future we can try to align the major releases of c.g/c.n and new ansible major releases better 18:59:25 samccann: as far as an overall, ansible package policy/thought, the first beta is when I'm going to freeze the versions. 18:59:36 yeah this first release I think we should just go for it.. pack in what we have 18:59:37 this time it's somewhat separated because everything's new and we need to make sure nothing breaks 18:59:43 felixfontein: as an exception, i think, we can release c.g. once out of the schedule:D 19:00:12 So even if c.g released 2.0.0 between now and beta, it would go into ansible-2.10.0 19:00:28 otherwise new content has to wait for 1.1.0, to be released by end of september, which will probably end up in 2.10.1 or 2.10.2 19:00:48 abadger1999: there are no plans for that :) 19:01:17 (and I'd vote against them if anyone comes up with that idea - it would wreak havoc with the deprecation cycles) 19:01:19 https://github.com/ansible-collections/overview/pull/101 19:01:29 i'm still +1 for revving to 1.1.0 to get the most recent (presumably stable) stuff into 2.10 19:01:31 to wait is also good. ~2 months 19:01:36 * acozine has to drop off for meeting with her boss 19:02:49 acozine: thanks a lot! 19:03:11 does someone wants to continue discussing, or should we vote? 19:05:34 seem nobody. let's vote then? 19:05:43 what does mean revving ? reviewing ? 19:06:14 update to a new version. 19:06:19 sorry being lazy with the typing. bumping up the revision to 1.1.0 19:06:45 https://www.merriam-webster.com/dictionary/revving 19:07:00 I've no opinion as I did not look the difference between theses branches 19:07:01 TIL the word revving 19:07:11 :) 19:07:12 * baptistemm too 19:07:27 POLL: +1 = release 1.1.0 before beta freeze, -1 = do not 19:07:33 +1 19:07:44 both work for me 19:07:54 1 and -1 19:08:08 whatever the better is for you 19:08:20 +1 19:08:55 baptistemm: the release process is not that complicated, from that point of view both is fine for me 19:09:12 22/11 *4 ^^2 -3 19:09:38 +1 so 19:09:43 +1 19:09:51 persuaded:) 19:09:55 0, either is fine or me. 19:10:03 #chair 19:10:03 Current chairs: abadger1999 acozine andersson007_ baptistemm cyberpear felixfontein geerlingguy gregdek samccann 19:10:17 +1 from me 19:11:10 ok 19:12:18 #agreed release 1.1.0 of c.g and c.n before 2.10.0 beta freeze if there's content (5 x +1, 1 x 0) 19:12:21 cool! 19:14:07 ok, I guess we should postpone the discussion on moving stuff to next week, so we have more time for it 19:14:13 (instead of squeezing it in now) 19:14:21 (also I'd like to hear g.'s opinion on it) 19:14:26 is that ok for everyone? 19:14:49 what's next on the agenda ? 19:15:18 fine with punting to next week since we're already over the 1 hr mark 19:15:28 ok for me 19:15:31 +1 19:15:43 to postpone 19:15:56 it's late for you perhaps you deserve some rest as well 19:16:06 22.16 19:16:16 in my area 19:16:18 baptistemm: next would be https://github.com/ansible/community/issues/539#issuecomment-656098926 and https://github.com/ansible/community/issues/539#issuecomment-669279701 19:16:29 which belong in the same discussion IMO 19:16:59 and the moving ship has sailed for 2.10.0 anyway, so it's not urgent that we have to discuss it today 19:17:22 so you're starting the discussion :) ? 19:17:30 ah no 19:17:35 ok to review later 19:17:42 btw, stats from Ansible 2.10.0 collection repos: one is https://opendev.org/openstack/ansible-collections-openstack.git, one repo link does not work (azure), and all other repo links are to github 19:18:10 Cool. 19:18:26 ah yea I wondered why azure and not azure.cloud as other cloud providers 19:18:37 I now have a firefox window open with all collection repos in it 19:19:07 21:16 < andersson007_> 22.16 19:19:11 oops 19:19:13 https://galaxy.ansible.com/community/azure 19:19:15 I meant to paste this 19:20:16 #topic open floor 19:20:25 anything spontaneous that should be covered today? 19:20:36 (I'll close at :25 if nobody has anything) 19:25:25 I guess not then? 19:25:27 #endmeeting