18:00:27 <felixfontein> #startmeeting Ansible Community Meeting
18:00:27 <zodbot> Meeting started Wed Sep  9 18:00:27 2020 UTC.
18:00:27 <zodbot> This meeting is logged and archived in a public location.
18:00:27 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:27 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:41 <cyberpear> o/
18:00:48 <gundalow> Just interviewing someone, will be here shortly
18:00:53 <felixfontein> abadger1999: acozine: gundalow: andersson007_: cyberpear: samccann:
18:00:58 <felixfontein> #chair cyberpear
18:00:58 <zodbot> Current chairs: cyberpear felixfontein
18:01:02 <felixfontein> #chair gundalow
18:01:02 <zodbot> Current chairs: cyberpear felixfontein gundalow
18:01:04 <andersson007_> рш
18:01:07 <andersson007_> hi sorry
18:01:10 <felixfontein> #chair andersson007_
18:01:10 <zodbot> Current chairs: andersson007_ cyberpear felixfontein gundalow
18:01:39 <felixfontein> andersson007_: was that russian? or just random cyrillic? :)
18:01:49 <andersson007_> random:)
18:02:07 <felixfontein> gwmngilfen: are you around?
18:02:23 <andersson007_> felixfontein: привет (hi)
18:02:40 <abadger1999> Hi
18:02:47 <felixfontein> #chair abadger1999
18:02:47 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear felixfontein gundalow
18:02:54 <felixfontein> andersson007_: ok :)
18:02:54 <gwmngilfen> Not really :)
18:03:16 <felixfontein> gwmngilfen: no problem :)
18:03:20 <gwmngilfen> Do you need me? Just about to do bedtime with the kids.
18:03:25 * samccann waves
18:04:01 <felixfontein> #chair samccann
18:04:01 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear felixfontein gundalow samccann
18:04:11 * gwmngilfen makes a note to check in with acozine about doc stats :)
18:04:13 <felixfontein> gwmngilfen: andersson007_: I'm not sure, do you want to continue the discussion from last week?
18:04:40 <andersson007_> didn't think of it:)
18:04:41 <felixfontein> #topic agenda: https://github.com/ansible/community/issues/539
18:05:01 <andersson007_> i thought gwmngilfen will prepare something to Ansible Fest
18:05:13 <gwmngilfen> No progress on the dash from me, planning to do some initial work on it tomorrow & Friday.
18:05:14 <andersson007_> based on what we discussed last time
18:05:18 <felixfontein> ah yes, now I remember
18:05:27 <felixfontein> darn, that week felt long
18:05:33 <felixfontein> (or is it me getting old?)
18:05:37 <gwmngilfen> Yes, I do want something by then, but I'm aiming for earlier so we can review
18:05:53 <andersson007_> felixfontein: usually it's getting faster:)
18:06:01 <felixfontein> :)
18:06:01 * acozine waves
18:06:03 <andersson007_> the older we are
18:06:04 <felixfontein> #chair acozine
18:06:04 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gundalow samccann
18:06:50 <felixfontein> #topic updates
18:08:20 <felixfontein> #info ansible-base 2.10.1 was delayed by one week, which means that the ansible 2.10.0rc1 will also get delayed by one week (now planned for 2020-09-15)
18:08:37 <felixfontein> #info ansible 2.10.0 release is currently planned for 2020-09-22
18:10:51 <abadger1999> Closing in on release date :-)
18:11:06 <felixfontein> abadger1999: in https://github.com/ansible-collections/overview/issues/45#issuecomment-687513849 you wrote that we'll have a meeting on 2020-09-17 where we discuss whether there are blockers or not. that's not the regular community meeting, right?
18:11:12 <felixfontein> definitely :)
18:11:23 <felixfontein> I think a lot of people look forward to it
18:11:30 <felixfontein> not only the ones using ansible-lint ;)
18:12:13 <abadger1999> Darn.
18:12:30 <abadger1999> I meant to use the meeting on the 16th.
18:12:51 <felixfontein> I just wanted to say that we discuss it next week, when I noticed that it's the wrong day
18:13:11 * abadger1999 checks if he wrote  the 17th everywhere...
18:13:17 <felixfontein> I hope there are no blockers, in which case we'd have a very short meeting ;)
18:14:06 <felixfontein> https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst also says 17
18:14:53 <abadger1999> yeah.
18:15:01 <abadger1999> Okay, is that good for you/everyone?
18:15:16 <abadger1999> Otherwise I can publish that the 17th was a mistake everywhere.
18:15:37 <felixfontein> 17th? should be fine, if it's not too early
18:15:41 <abadger1999> Cool.
18:15:47 <abadger1999> Same time as this meeting?
18:15:47 <samccann> special meeting on the 17th sounds good to me.
18:15:53 <acozine> I'll be out both days (16th, 17th)
18:16:03 <samccann> I'm out on the 16h
18:16:07 <abadger1999> Heh :-)
18:16:07 <samccann> 16th that is
18:16:08 <acozine> but a special pre-release meeting sounds like a good idea
18:16:45 * acozine has movers coming and is bracing for several days of domestic chaos
18:17:19 <felixfontein> sounds like "fun"
18:17:40 <felixfontein> good luck :)
18:18:42 <felixfontein> gundalow: is 17th at 18:00 UTC fine for you?
18:19:52 <abadger1999> Cool, Since it's not a regularly scheduled meeting, I'll post a followup to the places I announced the meeting with 17th at 18:00UTC,  in #ansible-community.  I'll ask that anyone who has something they would like upgraded puts it on the meeting agenda ahead of time so that we can stop the meeting after five to ten minutes if there is nothing listed.
18:20:54 <abadger1999> gundalow and I have an internal meeting then but I think only one of us needs to attend or we can quickly give status in the other meeting if there turns out to be a debate on something here.
18:21:26 <felixfontein> sounds good
18:21:57 <felixfontein> #info meeting at 2020-09-17 18:00 UTC about whether there are blockers for ansible 2.10.0
18:23:01 <felixfontein> any more announcements? :)
18:23:46 <acozine> can't think of anything
18:24:00 <felixfontein> if not, we could talk about (a) testing requirements for c.g/c.n, (b) moving content between collections after 2.10.0, (c) something else?
18:24:13 <samccann> oh isn't there a drop dead date on rc1 for no more collections changes?
18:24:35 <samccann> ^^ as in worth an info for the meeting minutes?
18:24:49 <andersson007_> (i have to leave the meeting for some time)
18:25:44 <felixfontein> #info rc1 means complete freeze, except for blockers: i.e. even if we have another rc, collections will only get updated if needed to remove blockers
18:25:55 <felixfontein> samccann: I hope ^ makes sense :)
18:26:25 * acozine waves at andersson007_
18:26:35 <abadger1999> andersson007_: So long!
18:26:38 <samccann> #info that means no patch releases in any collections after RC1 is created, unless it fixes a blocker
18:26:42 <felixfontein> andersson007_: see you!
18:27:00 <samccann> felixfontein - hoping that add-on info is correct :-)
18:27:20 <felixfontein> samccann: if you mean patch releases that get included, then yes :) collections can release whatever they want, we'll just ignore it most of the time ;)
18:27:48 <samccann> heh true
18:27:49 <felixfontein> btw, from action items three weeks ago (when we also discussed testing):
18:27:52 <felixfontein> @gundalow to create Etherpad for policy, assign meeting logs
18:27:55 <felixfontein> @gundalow to setup meeting, maybe felixfontein & cyberpear (EDT) could help?
18:28:24 <samccann> does that work ^^ for action ?
18:28:43 <felixfontein> no, I just copied the text over here, as a reminder ;)
18:28:46 <samccann> oh haha nevermind... older action items... thought it was an irc trick
18:29:05 <felixfontein> I forgot about it until now, and maybe gundalow did too :)
18:29:35 <gundalow> oh woops
18:29:40 <gundalow> can you `#action` that please
18:29:44 * gundalow returns to interview
18:29:53 <felixfontein> #action gundalow to create Etherpad for policy, assign meeting logs
18:30:00 <felixfontein> #action gundalow to setup meeting, maybe felixfontein & cyberpear (EDT) could help?
18:31:31 <felixfontein> about the testing requirements, we discussed that some time three weeks ago, and I think the only part we hadn't voted on was whether to expect tests that actually run in CI, or whether we're also happy with tests which don't run in CI (i.e. `unsupported` tests)
18:34:06 <felixfontein> hi aminvakil!
18:34:34 <aminvakil> hi felixfontein
18:34:48 <acozine> are there other actions or decisions we can make about testing?
18:35:23 <felixfontein> acozine: not sure... so far we voted that we want to have tests with new modules/plugins, IIRC
18:35:26 * acozine is typing on a laptop keyboard instead of her usual split keyboard . . . and it's really slow
18:37:10 <felixfontein> aminvakil: do you have opinions about whether new modules/plugins should have tests that run in CI, or whether integration tests that don't run in CI are also ok? :)
18:37:37 <felixfontein> #topic test requirements for new plugins/modules
18:38:43 <aminvakil> as far as I can tell from my experience it does help a lot having an integration test.
18:39:20 <felixfontein> I agree
18:39:25 <aminvakil> it can help whether the contributor and maintainers to make sure that the module is working as expected
18:39:53 <felixfontein> unfortunately sometimes accounts or special software/hardware are required to run integration tests
18:40:04 <acozine> isn't that what Zuul is for?
18:40:09 <felixfontein> (in which case they usually don't run in CI, and are marked as `unsupported`)
18:40:35 <felixfontein> acozine: depends :)
18:41:47 <felixfontein> I thought it's mainly used for tests with network devices, no idea whether it's also used with cloud providers etc.
18:41:49 <aminvakil> felixfontein: exactly, I was totally wrong about a PR which needed github private key and I couldn't fix it until I set it up on my local environment.
18:42:13 <felixfontein> in any case, for most modules in c.g which need something external it is probably too much effort to set up something like that
18:45:17 * gundalow returns
18:45:26 <acozine> we can go with "users are our CI" for integration
18:45:41 <felixfontein> welcome gundalow!
18:45:48 <felixfontein> acozine: true.
18:46:03 <felixfontein> I'd prefer tests that run in CI, but for modules I don't need I can also live with ones that don't ;)
18:47:36 <felixfontein> who actually would want to vote on this?
18:48:05 <gundalow> Are we talking about c.g and c.n, or c.* or *?
18:48:11 <felixfontein> (on whether at least some tests per new module/plugin must run in CI, or whether it is ok if none run in CI.)
18:48:15 <felixfontein> c.g and c.n
18:48:38 <felixfontein> for smaller collections it is easier to set up testing for everything, or to do manual testing
18:48:56 <gundalow> yup
18:49:42 <gundalow> So I guess the questions are
18:49:42 <gundalow> MUST vs SHOULD
18:49:42 <gundalow> runable in CI or included-but-disabled (for where we don't have the hardware/service)
18:50:24 <samccann> what were the requirements when all modules etc were in ansible/ansible?
18:50:33 <felixfontein> (usually they are marked as `unsupported`, not as `disabled` - `disabled` is for tests which could work in CI, but are disabled because they are broken, fail too often, or use too many resources)
18:50:33 <gundalow> And if people think it's OK to set the requirement high, and depending on feedback if we lower it in the future
18:50:48 <gundalow> felixfontein: ah, thank, yes, `unsupported` is what I meant
18:51:06 <felixfontein> samccann: good question
18:51:45 <felixfontein> I think last time (i.e. three weeks ago) there were several who prefered to not require tests that run in CI
18:53:57 <samccann> is there any bot magic that could apply here? if no CI tests present in a PR, put a comment suggesting they include CI and a pointer to a doc to help?
18:54:08 <samccann> aka make it a SHOULD with an automated nag?
18:54:46 <gundalow> <clippy> Hey, looks like you've added a new module without integration tests, would you like help with that <link to docs>?
18:54:54 <samccann> LOL
18:54:59 <felixfontein> hehe :)
18:55:06 <cyberpear> I'd say require them in CI if possible, otherwise mark them unsupported until (if) resources make them available in CI
18:55:16 <felixfontein> bot magic sounds good, though someone has to implement that ;)
18:55:28 <felixfontein> cyberpear: unit tests are *always* possible :)
18:56:13 <gundalow> Bot already knows what files are in the patch, and if something is a new_module. It's a bit of work to get a development instance of the bot running though
18:56:30 <cyberpear> ok. I guess I'm saying for integration tests. unit tests can pass with still broken modules
18:56:41 <felixfontein> gundalow: btw, are there instructions on how to set up a development instance?
18:57:33 <felixfontein> cyberpear: true. but integration tests can also ignore the fact that most of the module is broken
18:58:22 <felixfontein> so how about requiring tests, that SHOULD run in CI whenever feasible, and have the bot remind people if possible that they could/should add tests?
18:58:39 <felixfontein> I think everyone seems to be in favor for that
18:59:12 <felixfontein> should we vote on that?
18:59:28 <samccann> vote early, vote often :-)
19:00:05 <felixfontein> VOTE: For new modules/plugins in community.general and community.network, we require tests, which SHOULD run in CI whenever possible
19:00:10 <felixfontein> #chair
19:00:10 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gundalow samccann
19:00:14 <felixfontein> +1
19:00:18 <samccann> +1
19:00:21 <acozine> +1
19:00:21 <cyberpear> +1
19:00:31 <abadger1999> No opinion :-)
19:00:35 * acozine has to go interview a potential tech writer now
19:00:37 <felixfontein> #chair aminvakil
19:00:37 <zodbot> Current chairs: abadger1999 acozine aminvakil andersson007_ cyberpear felixfontein gundalow samccann
19:00:46 <aminvakil> +1
19:00:47 <felixfontein> acozine: see you!
19:00:57 <felixfontein> aminvakil: sorry for not converting you into furniture earlier ;)
19:01:18 <aminvakil> felixfontein: ;)
19:01:25 <jtanner> if it's not required, who's going to abide by the rule?
19:01:34 <gundalow> +1
19:01:36 <jtanner> people ignore nagging bots
19:01:49 <felixfontein> jtanner: these things still need to get merged, and right now the people who do that really like tests ;)
19:02:46 <jtanner> i like tests too and would have preferred they were required long ago, but i'm still not sure why any rule should be made that doesn't get enforced
19:03:22 <gundalow> If not tests then requires a +3, rather than +2 to merge?
19:03:28 <felixfontein> jtanner: the rule of having tests will get enforced
19:04:00 <felixfontein> it's mainly the rule of "test SHOULD run in CI" that's problematic, but SHOULD is not MUST
19:04:05 <jtanner> i guess i'm confused by the "WHENEVER possible" then, because that sounds like a not-enforced thing
19:04:26 <felixfontein> gundalow: right now new modules/plugins are merged manually. (in fact everything is merged manually, but that will hopefully change)
19:04:35 <cyberpear> "must have tests. should run automatically in CI"
19:05:03 <aminvakil> jtanner felixfontein: actually that's my question too, who decides whether it is possible or not?
19:05:27 <gundalow> I'm OK to test out MUST for a while and see how it goes
19:05:38 <felixfontein> jtanner: I guess it will be up to the people who can merge - if I think something can have tests, I won't merge it. no idea what other people with merge rights will do though :)
19:05:50 <jtanner> i feel that the contributors level of capability and desire to work at it is the ultimate decider of "SHOULD"
19:05:57 <felixfontein> (though andersson007_ usually asks for tests a lot more than me, and it's mainly him and me who currently merge PRs in c.g)
19:06:46 <felixfontein> we could also say that exceptions to "MUST run in CI" must be granted by the community meeting
19:06:51 <felixfontein> no idea how efficient that will be tough
19:06:54 <felixfontein> +h
19:07:48 <felixfontein> at the moment the main cases where we have new modules with unsupported tests is when there are new modules for an existing group of modules without tests (or without tests in CI)
19:09:08 <felixfontein> #info For new modules/plugins in community.general and community.network, we require tests, which SHOULD run in CI whenever possible (6 x +1, 1 x abstain)
19:09:14 <felixfontein> (before we forget about that)
19:10:05 <felixfontein> what do you think about only allowing tests which don't run in CI when the community meeting agrees? and on which basis/guidelines do we want to decide this?
19:11:12 <abadger1999> I think the community meeting could become a bottleneck.  But there does need to be a "court of last resort" which I suppose is the community meeting.
19:11:44 <abadger1999> I suppose the question is whether you want to build the meeting into the default process or only in sxceptional circumstances.
19:11:52 <jtanner> what's the recourse when the meeting says "no"? Contributor is then told to figure out how to make CI capable tests?
19:12:08 <felixfontein> I'd prefer it to handle exceptional circumstances, but for that we need some guidelines / rules for the default process
19:12:33 <felixfontein> jtanner: yes, or someone else can create tests for the PR or help the author with them
19:13:28 <jtanner> very well
19:16:19 <geerlingguy> Oh shoot did I miss the meeting?
19:16:36 <gundalow> geerlingguy: started 76 minutes ago
19:16:46 <felixfontein> time to stop soon :)
19:16:53 <gundalow> geerlingguy: import by URL (don't download as you won't get updates) https://raw.githubusercontent.com/ansible/community/master/meetings/ical/community.ics
19:16:55 <felixfontein> geerlingguy: sorry, should have pinged you too!
19:16:58 <felixfontein> #chair jtanner geerlingguy
19:16:58 <zodbot> Current chairs: abadger1999 acozine aminvakil andersson007_ cyberpear felixfontein geerlingguy gundalow jtanner samccann
19:17:18 <geerlingguy> drat. Well I made it for the very end :) — I have that calendar in mine, but it doesn't have an alarm. I'm going to set up a separate event with alarm now.
19:17:39 <gundalow> geerlingguy: ah yes, I think you need to duplicate to get an alarm :(
19:18:39 <felixfontein> hmm, do you want to continue this discussion, or should we postpone (again)?
19:18:54 <felixfontein> geerlingguy: in case you wonder, we didn't got to the content moving discussion yet :)
19:19:04 <felixfontein> (if you were waiting for that one)
19:22:29 <felixfontein> #topic open floor
19:22:37 <felixfontein> I guess let's postpone it...
19:22:45 <felixfontein> anyone has something else to discuss?
19:24:17 <gundalow> just one thing
19:24:24 <gundalow> which I don't think I mentioned last time
19:24:59 <gundalow> https://www.katacoda.com/gundalow/scenarios/fixing-a-bug https://github.com/ansible-community/katacoda-scenarios/tree/master/fixing-a-bug
19:25:42 <felixfontein> do you want to #info that?
19:26:58 <gundalow> #info We've been prototyping using Katacoda.com for an interactive scenario (checkout collections, run CI (fails), fix bug, run CI (pass), add changelog, commit) https://www.katacoda.com/gundalow/scenarios/fixing-a-bug https://github.com/ansible-community/katacoda-scenarios/tree/master/fixing-a-bug
19:27:13 <felixfontein> sounds cool!
19:28:14 <samccann> neat!  are the at the point where we can mention/point to them from the 'developing collections' docs?
19:29:13 <gundalow> samccann: 1) Needs more explanation + wordsmithing 2) Moved out of `/gundalow` 3) People to say they like it
19:29:24 <samccann> kewl!
19:31:30 <felixfontein> #endmeeting