18:00:34 <felixfontein> #startmeeting Ansible Community Meeting
18:00:34 <zodbot> Meeting started Wed Aug 19 18:00:34 2020 UTC.
18:00:34 <zodbot> This meeting is logged and archived in a public location.
18:00:34 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:34 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:41 <felixfontein> so who's there?
18:00:43 <andersson007_> hi everyone
18:00:47 <felixfontein> #chair andersson007_
18:00:47 <zodbot> Current chairs: andersson007_ felixfontein
18:01:00 <felixfontein> abadger1999: gundalow: cyberpear: samccann: acozine: ping
18:01:07 * gundalow waves
18:01:10 <abadger1999> Greetings :-)
18:01:13 <samccann> \o
18:01:27 <acozine> o/
18:01:52 <maxymvlasov> hi
18:02:26 <felixfontein> #chair gundalow abadger1999 samccann acozine maxymvlasov
18:02:26 <zodbot> Current chairs: abadger1999 acozine andersson007_ felixfontein gundalow maxymvlasov samccann
18:02:28 <felixfontein> hi all!
18:02:31 <felixfontein> welcome maxymvlasov!
18:03:47 <felixfontein> about today: I guess `Testing of Ansible 2.10 beta` and `Some sort of longer message about how policies are changing` posted by gundalow are most pressing issues, , and then `test requirements for new modules/plugins in community.general and community.network`
18:04:03 <felixfontein> should we start with these? or has anyone something else that's (more) urgent?
18:04:30 <abadger1999> works for me.
18:04:54 <acozine> felixfontein: can you post a link to the agenda?
18:05:09 <felixfontein> #info agenda: https://github.com/ansible/community/issues/539
18:05:12 <acozine> thanks!
18:05:18 <felixfontein> yw!
18:05:19 <gundalow> abadger1999: Got a link to the "How to Test" notes yo umade?
18:05:36 * abadger1999 finds it
18:05:58 <andersson007_> `test requirements for new modules/plugins in community.general and community.network` what are the options?
18:06:10 <andersson007_> suggested
18:06:13 <andersson007_> ?
18:06:18 <abadger1999> https://gist.github.com/abadger/e3411e92218c9e07b70b5469f623f96a
18:06:26 <abadger1999> Shoot  not that one.
18:06:28 <gundalow> maxymvlasov: Hi, thanks for joining :)
18:07:19 <felixfontein> andersson007_: I guess "all new modules/plugins MUST have tests that run in CI", or "... MUST have some kind of tests (possibly unsupported)", or the same with SHOULD
18:07:23 <abadger1999> https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases#bugs-in-modules-and-plugins
18:07:30 <abadger1999> That is the correct one ^
18:07:40 <gundalow> #topic Testing ansible
18:07:50 <gundalow> abadger1999: ah, wiki, no wonder I couldn't find it, thanks
18:08:01 <andersson007_> felixfontein: ok, i'm in faivor of SHOULD
18:08:18 <andersson007_> if possible MUST
18:08:22 <gundalow> #info As we are getting close to ansible 2.10, we need to get extra help from people to test the new ansible package
18:08:28 <felixfontein> andersson007_: I'd prefer MUST, to avoid all discussion whether it's ok to leave tests away for a module/plugin or not. but let's discuss this when the topic's up
18:08:41 <gundalow> #info https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases#bugs-in-modules-and-plugins has some details
18:08:54 <gundalow> Q: What else do we need people to explicitly test
18:09:01 <gundalow> Q: What are the known issues
18:09:33 <abadger1999> I can get two known issues from the release announcements.
18:09:50 <felixfontein> known issues are that some redirects do not work yet, or currently point to the wrong version (some will get fixed for RC because it requires ansible-base 2.10.1)
18:11:23 <acozine> +1 for `must` - some folks will still ignore it, but it makes the situation clear
18:13:15 <felixfontein> abadger1999: do you want to mention the others?
18:13:38 * resmo waves
18:13:38 <andersson007_> acozine: `must` also works for me. just trying to imagine cases when they are not possible
18:13:41 <gundalow> What's missing from https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases
18:13:46 <gundalow> #chair resmo
18:13:46 <zodbot> Current chairs: abadger1999 acozine andersson007_ felixfontein gundalow maxymvlasov resmo samccann
18:13:51 <felixfontein> (I guess you mean `ansible-galaxy collection list` and `pip install --upgrade ansible`?)
18:14:02 <abadger1999> yeah.
18:14:18 <abadger1999> ansible-galaxy collection list does not list the collections included in the ansible package.
18:14:25 <acozine> gundalow: link to the installation guide, maybe?
18:14:28 <felixfontein> gundalow: the known issues should definitely be added
18:14:38 <abadger1999> pip install --upgrade doesn't work.  You have to uninstall first.
18:14:43 <felixfontein> abadger1999: will this get fixed for ansible-base 2.10.1, or only for 2.11.0?
18:14:49 <abadger1999> I've added those two to a new section of the page.
18:15:13 <abadger1999> felixfontein: The first should get fixed in 2.10.x (maybe .1 or maybe .2... depends on when tests get added to the PR)
18:15:25 <acozine> I'd link to https://docs.ansible.com/ansible/2.10/installation_guide/intro_installation.html#installing-ansible-with-pip for details about upgrading
18:15:30 * abadger1999 adding the redirects bug to the wiki page
18:15:30 <acozine> with pip
18:17:19 <felixfontein> gundalow: you mentioned that some more updates for ansible_base_runtime.yml are needed yesterday (IIRC), did you already create a PR for that?
18:17:42 <felixfontein> (I think it was skydive.skydive -> community.skydive)
18:18:29 <gundalow> felixfontein: not had any time yet :(
18:18:41 <felixfontein> the two redirect PRs I know about are https://github.com/ansible/ansible/pull/71081 and https://github.com/ansible/ansible/pull/71264
18:19:07 <cyberpear> o/
18:19:09 <felixfontein> gundalow: I'll create a PR then
18:19:11 <felixfontein> #chair cyberpear
18:19:11 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gundalow maxymvlasov resmo samccann
18:19:18 <gundalow> felixfontein: most kind
18:20:07 <abadger1999> https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases#known-bugs
18:20:18 <abadger1999> I think I've captured everything mentioned so far into that section.
18:20:21 <acozine> felixfontein: shall I merge those redirect PRs?
18:20:57 <acozine> they're both passing CI
18:21:08 <felixfontein> acozine: I don't know whether this should be done by RM(s) or whether it is ok if you merge them
18:21:31 <acozine> mmm, good point
18:22:02 <felixfontein> gundalow: https://github.com/ansible/ansible/pull/71357
18:22:27 <felixfontein> I wouldn't mind if they are merged ASAP to make it clear that they definitely will be in ansible-base 2.10.1
18:22:36 <felixfontein> but probably it makes sense to wait until the third backport is there as well
18:24:45 <felixfontein> ok, more things for https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases ?
18:26:55 <abadger1999> gundalow: What are your next steps for the document?
18:29:24 <gundalow> abadger1999: I guess reddit it along with the release announcement?
18:29:51 <abadger1999> Sounds good.
18:30:06 <gundalow> #action gundalow merge https://github.com/ansible/ansible/pull/71357
18:30:38 <gundalow> #action gundalow reddit release announcement + https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases
18:30:41 <gundalow> Thanks
18:30:44 <gundalow> next topic?
18:30:45 <felixfontein> great!
18:30:57 <felixfontein> `Some sort of longer message about how policies are changing`
18:31:20 <felixfontein> gundalow: that's also your topic?
18:31:49 <felixfontein> acozine: thanks! :)
18:32:07 <acozine> yw
18:32:19 <acozine> I did ask the RMs
18:32:41 <gundalow> #topic Collection Policies
18:32:47 <gundalow> I think this was abadger1999's
18:33:37 <abadger1999> So... I think we should assemble a list of end user visible policies that differ between ansible-2.9 and ansible-2.10.
18:33:58 <abadger1999> Then when I make the release announcement for ansible-2.10, we can include a link to that document.
18:34:27 <abadger1999> I have some examples in the issue.  But we need to add more things, clarify wording, etc.
18:34:33 <felixfontein> +1
18:34:53 <samccann> got a link handy to the issue?
18:34:55 <abadger1999> tangentially... we probably also want a list of policy decisions other than the meeting logs too ;-)
18:35:18 <felixfontein> #info https://github.com/ansible/community/issues/556
18:36:32 <felixfontein> yep, reading up everything in the meeting logs is very tedious
18:37:06 <samccann> does this belong in a blog post or on docs.ansible.com?
18:37:10 <cyberpear> do we need an "enhancements" repo to track such policies, etc?
18:37:13 <felixfontein> https://github.com/ansible-collections/overview/blob/master/collection_requirements.rst also contains some of them, it should definitely be linked
18:37:15 <acozine> and/or in The Bullhorn?
18:37:30 <cyberpear> I guess "overview" is closest we have now
18:37:32 <abadger1999> samccann: I think policies themselves probably belong on either docs.a.c or on the community/wiki.
18:37:37 <felixfontein> cyberpear: I guess we could put it in overview as well
18:37:42 <felixfontein> cyberpear: you type faster ;)
18:37:44 <cyberpear> (how many subscribed to bullhorn?)
18:38:14 <acozine> I don't know, but we should encourage people to subscribe
18:38:18 <abadger1999> samccann: Something that is for end users switching from 2.9 to 2.10.... I'm not sure... I was thinking the tone of voice would be more appropriate to a blog post but the content would certainly be enduring.
18:38:19 <felixfontein> abadger1999: how about https://github.com/ansible-collections/overview/blob/master/policies.rst ?
18:38:45 <abadger1999> felixfontein: Sure.  that works too.
18:39:17 <felixfontein> I think it would be good to (also) have a more formal version, which lists everything in detail, and maybe an easier to read sum-up (which might miss some edge-cases)
18:39:26 <abadger1999> <nod>
18:41:08 <felixfontein> so... who wants to write it? ;)
18:42:17 <gundalow> Do we have the source material somewhere?
18:42:37 <abadger1999> If we only assemble something that misses some details, do we only want the easier to read sum-up?
18:42:53 <acozine> if I know what the rules are, I can certainly write them up neatly
18:42:55 <abadger1999> The source material would probably be the meeting logs or the meeting agenda.
18:43:15 <abadger1999> (Which is a problem in and of itself)
18:43:18 <gundalow> if not having something like a Google Doc might be easier to crowd source the content first, then wordsmith and convert to RST
18:43:18 <acozine> heh
18:43:46 <gundalow> When do we need this by (before 2.10.0)?
18:44:00 <abadger1999> i think we do need the sum-up before 2.10.0.
18:44:15 <felixfontein> I guess it would be good to have it ready for 2.10.0, or even a few days before
18:44:33 <abadger1999> I'd like to put out a draft release announement for people to comment on and add things to as well.  So it would be good to have it ready sooner.
18:44:38 <abadger1999> Yep, exactly felixfontein .
18:45:08 <gundalow> cyberpear: 466 people subscribed to The Bullhorn
18:45:29 <cyberpear> gundalow++ great!
18:45:30 <zodbot> cyberpear: Karma for gundalow changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:45:58 <gundalow> Do we need to setup a call where we go through log-by-log and hack stuff around a bit?
18:46:37 <felixfontein> who is 'we' in this question?
18:47:07 <gundalow> who ever is interested
18:47:49 <cyberpear> log-by-log?
18:48:43 <felixfontein> I guess we can skip most of the community.general / community.network discussions (i.e. most of the first couple of meetings)
18:48:59 * cyberpear understands now
18:49:05 <gundalow> cyberpear: IRC log
18:50:04 <cyberpear> right, check at least any instances of #agreed, and peruse preceding discussion if unclear
18:51:57 <cyberpear> I'd be game to hop on such a call if I'm otherwise available
18:52:18 <gundalow> cyberpear: remind me what TZ you are in
18:52:27 <cyberpear> EDT, UTC-4
18:52:55 <cyberpear> America/New_York if you're setting you system clock :P
18:53:06 <bcoca> i run in BCS timezone
18:53:21 <cyberpear> your very own? :P
18:53:24 <abadger1999> gundalow: If you want, (and since I'm likely the only US west coast TZ), you can assign me one or two meeting logs to go through and then I can add any policies I find in there.
18:53:26 <felixfontein> S for summer?
18:53:37 <bcoca> my 2nd surname Segura
18:53:43 <felixfontein> bcoca: ah ok :)
18:53:55 <felixfontein> I was wondering whether you care about summer/winter
18:54:33 <gundalow> Do we think Public Google Doc?
18:55:22 <felixfontein> or this other thing that we use for the community summits (I always forget its name)?
18:55:31 <felixfontein> ah contributor summits
18:55:35 <felixfontein> (damn I'm bad with names :D )
18:55:42 <acozine> etherpad?
18:55:51 <misc> hackmd ?
18:56:00 <cyberpear> hackmd?
18:56:04 <felixfontein> yep etherpad it was
18:56:11 <andersson007_> felixfontein: community == contributors
18:56:37 <felixfontein> andersson007_: true, but the official name of the meeting is Contributor Summit, not Community Summit :)
18:57:28 <andersson007_> felixfontein: i think we all understand what you mean:)
18:57:36 <andersson007_> so don't worry much:)
18:57:44 <felixfontein> I'm trying ;)
18:59:50 <abadger1999> Okay, so it sounds like, set up a meeting, go through logs... You can assign a few to me...
18:59:55 <gundalow> Thanks
19:00:21 <abadger1999> Do you want to take the action item to do the setup?
19:00:35 <gundalow> #action gundalow to create doc for policy, assign meeting logs
19:00:41 <gundalow> #undo
19:00:41 <zodbot> Removing item from minutes: ACTION by gundalow at 19:00:35 : gundalow to create doc for policy, assign meeting logs
19:00:45 <felixfontein> I can also help with going through logs, whether I have time for the meeting depends on when it is
19:00:46 <gundalow> #action gundalow to create Etherpad for policy, assign meeting logs
19:01:00 <felixfontein> cool
19:01:10 <gundalow> oh, on the point of time, I'm out Mon-Wed next week
19:01:15 <gundalow> Thanks all
19:01:36 <felixfontein> do you want to discuss testing policy for community.general / community.network, or should we wind down the meeting for today?
19:01:45 <gundalow> #action gundalow to setup meeting, maybe felixfontein  & cyberpear (EDT) could help?
19:01:57 <felixfontein> (i.e. whether new plugins/modules should/must have tests, and whether these test should/must run in CI)
19:02:12 <gundalow> `SHOULD`
19:02:58 <felixfontein> #topic should/must new modules and plugins for community.general / community.network have tests? tests running in CI?
19:03:19 <felixfontein> the main drawback of SHOULD is that we end up with more new modules/plugins which do not have tests, or only tests which do not run in CI
19:03:32 <felixfontein> (and we already have inherited a huge amount of these :) )
19:04:02 <felixfontein> and while adding integration tests that run in CI can be very hard (especially if some setup is needed), usually adding some basic unit tests should be a lot simpler
19:04:03 <cyberpear> must for having tests, should for having them run in CI
19:04:04 <andersson007_> i think if possble to implement without special equipment, they must (even marked with `unsupported` alias, if not, they should
19:04:24 <acozine> yeah, I'd vote for `MUST` but then we have the problem of enforcement - what happens when a module/plugin doesn't have them?
19:04:27 <andersson007_> i am in favor of must
19:04:30 <resmo> cyberpear: +1
19:04:31 * abadger1999 is split... on the one hand, any SHOULD is really a "hey did you think about this" but in no way a requirement.  On the other hand, MUST is not something we'll really be able to review.
19:04:36 <felixfontein> acozine: if it is a new one, it won't get merged
19:04:43 <felixfontein> existing ones continue to rot ;)
19:04:48 <cyberpear> just don't pin the "MUST" on someone who's trying to bugfix a module w/o current tests
19:04:53 <cyberpear> that's always demotivating
19:04:54 <andersson007_> trying to think realisticaly
19:04:55 <felixfontein> I'm also in favor of must
19:04:59 <abadger1999> we can see... hey you have some tests... but we won't be able to tell whether those tests are good at their job or really really simplistic.
19:05:04 <felixfontein> cyberpear: it's not about existing modules/plugins, it is about new ones
19:05:06 <gundalow> cyberpear: yup, that's a really good point
19:05:18 <cyberpear> ^ been there, done that...
19:05:27 <andersson007_> haveing tests is always good
19:05:31 <andersson007_> even not working
19:05:35 <acozine> for new modules, I'd definitely say `must` then . . . and maybe we can make "Adding tests to legacy nonconforming modules" to a hackathon sometime?
19:05:46 <felixfontein> abadger1999: it's better to have some basic tests (so that at least loading the plugin/module works) instead of having nothing at all
19:05:58 <andersson007_> it helps realize a lot of things
19:06:04 <abadger1999> felixfontein: <nod>  Do we want to say that, then?
19:06:15 <felixfontein> I'm in favor ;)
19:06:17 <andersson007_> and avoid bugs, make interfaces clearer
19:06:24 <abadger1999> That at the least a test to check that the plugin loads must exist?
19:06:27 <andersson007_> for authors first of all
19:06:49 <abadger1999> (otherwise, I can write a universal test ;-)   `def test_anything(): assert True`   ;-)
19:07:00 <andersson007_> when they are creating modules
19:07:17 <felixfontein> abadger1999: well, as long as persons are merging new module/plugin PRs, it's hard to get such tests in ;)
19:07:27 <felixfontein> (or deciding whether to merge)
19:07:47 <gundalow> at JOB-2 we had a basic does it load test, which found more bugs that you might think
19:07:54 <felixfontein> cyberpear: your argument for 'should' was mainly for existing modules/plugins, right?
19:08:01 <acozine> gundalow: ouch
19:08:26 <cyberpear> felixfontein: "should" run in CI... some modules need something special to run, and hard to do w/o specialized services or hardware
19:08:28 <felixfontein> gundalow: I've already planned to add basic load tests to most plugins, but never found time for that
19:08:36 <abadger1999> If we're reviewing the tests, then should is viable, though.
19:08:40 <felixfontein> cyberpear: that's why there are unit tests :)
19:08:47 <cyberpear> felixfontein: in those cases, you can often write a test, but can't necessarily run it in CI
19:08:52 <cyberpear> that works, too
19:09:00 <andersson007_> for existing: if test are already exists, people must cover their fixes as well
19:09:13 <abadger1999> (unless we specify what the tests bed to do at s minimum)
19:09:16 <felixfontein> I usually recommend to people to write unit tests if they want to contribute a module/plugin which requires some special hardware/onlinee service/...
19:09:20 <cyberpear> except I've seen times where a module w/ unit tests passed those, but failed to load at all.
19:09:43 <cyberpear> so it's really best to have both, but sometimes unit tests is the best you can do
19:10:00 <cyberpear> I wonder if it's possible to have a generic, "does the module load?" test
19:10:01 <felixfontein> cyberpear: true. but at least it is a start, and people can improve it if it turns out that the test misses something
19:10:29 <felixfontein> cyberpear: I think having something generic is very hard or even impossible
19:11:00 <cyberpear> I guess the sanity tests are the closest thing.
19:12:10 <felixfontein> sanity testing for modules is a lot better than for plugins
19:12:18 <abadger1999> cyberpear: probably yes for a plugin (but we'd need to decide how to handle missing libraries and possibly write code for the test case to work with that case).  For modules, it's a little harder since those are not run in process.
19:12:19 <felixfontein> (there's validate-modules, but no equivalent for plugins)
19:13:27 <felixfontein> if we force the submitter of a new plugin/module to implement basic tests, we already have something to start with and we don't have to add that later for them
19:13:56 <gundalow> sivel has some WIP/hack stuff to make validate-modules support modules. I don't know how far along it is
19:14:05 <cyberpear> #proposed "new plugins to community.{general,network} MUST have integration or unit tests and these SHOULD run in shippable CI"
19:14:20 <acozine> +1
19:14:39 <felixfontein> cyberpear: I'd even ask for MUST for at least some of the tests
19:14:49 <andersson007_> my vote is for: new stuff must have CI tests even with `unsupported` alias but with sane exceptions.
19:15:06 <andersson007_> and they don't have to work in CI
19:15:18 <felixfontein> if tests don't work in CI, there's no guarantee that they work at all
19:15:27 <felixfontein> if they require some obscure hardware/service, it's impossible to run them yourself
19:15:46 <andersson007_> other contributors can run
19:16:02 <felixfontein> but what if there is no other contributor until two years later, and then it turns out the tests never worked?
19:16:02 <andersson007_> who work with the equipment
19:16:30 <andersson007_> oh, difficult question..
19:16:51 <felixfontein> that's why I prefer at least some basic unit tests which always run in CI :)
19:17:05 <gundalow> Also need some nice examples of some tests
19:17:18 <felixfontein> indeed!
19:17:20 <cyberpear> maybe, require tests that SHOULD run, but MUST have a successful run transcript included with the PR, including steps to reproduce?
19:17:38 <andersson007_> felixfontein: that's better than nothing but it also doesn't say the whole thing works as expected
19:17:46 <gundalow> Once I've got my three new hires, maybe they can work on the idea felixfontein had about something that does some basic loading
19:17:58 <gundalow> as well as making validate-modules work for plugins
19:17:59 <felixfontein> andersson007_: it doesn't, but at least something actually runs in CI ;)
19:18:16 <felixfontein> gundalow: that would be awesome!
19:18:18 <andersson007_> felixfontein: yes, i agree
19:18:52 <gundalow> for collections apart from c.g and c.n  I'd hope that most collections are requiring tests, though I haven't checked
19:19:09 <felixfontein> cyberpear: that's already better, but you still don't know how much work it is to actually reproduce it if you have the equipment/access to the service (the submitter could have forgot some "details")
19:19:34 <felixfontein> gundalow: I guess any collection which has maintainers which care about the content will ask for tests :)
19:20:12 <felixfontein> hmm
19:20:33 <felixfontein> I think MUST for having tests is clear. should we vote about SHOULD/MUST for run in CI?
19:20:36 <andersson007_> i think not working CI tests is also good:) help people make new stuff better, think interfaces over and over, etc:)
19:21:04 <abadger1999> Do we want to define "basic tests" a little bit?
19:21:39 <felixfontein> I guess for integration tests, "basic" would mean that at least the main operations are tested
19:22:03 <cyberpear> agreed about "basic tests"... would be good to have a documented example of "simplest possible test" or so for each plugin type
19:22:11 <felixfontein> for unit tests, "basic" means that a simulated run of the main operations is made, with hopefully not so much mocked that it says nothing
19:22:21 <andersson007_> i think all operations must be tested if possible and in check mode too
19:22:37 <felixfontein> cyberpear: you mean "simplest possible which still tests something" :D
19:22:44 <cyberpear> of course!
19:22:59 <acozine> "Your module doesn't do anything: change my mind."?
19:23:05 <cyberpear> lol
19:23:08 <felixfontein> andersson007_: that's already somewhat advanced ;) (and easier to add later)
19:23:28 <felixfontein> `assert True` :)
19:23:30 <cyberpear> yes, check_mode and diff_mode are very important to support, in my opinion
19:24:00 <andersson007_> felixfontein: i will claim anyway, otherwise no LGTM:)
19:24:22 <andersson007_> cyberpear: +1
19:24:25 <felixfontein> andersson007_: yep, you can of course always have higher standards and simply not approve a PR
19:24:28 <gundalow> This feels like a topic that could go on, where would we like to get to?
19:24:42 <cyberpear> `ansible-galaxy plugin init --type={module,filter,test,action}`
19:24:55 <andersson007_> felixfontein: in reality, if there are tests, it's not difficult to invoke all params:)
19:25:14 <felixfontein> #info consensus that new modules/plugins MUST have tests
19:25:29 <cyberpear> would generate the template files necessary for the module/filter_plugin/test_plugin, etc, including a template unit and integration test for it
19:25:30 <felixfontein> #info vote needed whether tests MUST run in CI, or SHOULD
19:25:30 <gundalow> +1
19:25:31 <andersson007_> any kind?
19:25:38 <felixfontein> #info definition of "basic" needed for tests
19:25:39 <cyberpear> SHOULD
19:25:56 <gundalow> cyberpear: yup, some sort of template/reference test would be good.
19:26:14 <felixfontein> do you want to continue discussing this, or should we postpone for next week?
19:26:24 * gundalow needs to drop
19:26:25 * cyberpear running out of time today
19:26:35 <andersson007_> let's postpone maybe?
19:26:38 <felixfontein> it's also getting late here :)
19:26:43 <andersson007_> yep..
19:26:44 <felixfontein> ok, then let's talk about this next week!
19:26:47 <gundalow> and I notice we are 86/60 minutes into the meeting
19:26:48 <andersson007_> cool
19:26:49 <gundalow> Thanks all
19:26:55 <felixfontein> everyeone can make up their mind on what "basic tests" mean until then ;)
19:27:01 <felixfontein> thanks everyone!
19:27:04 <felixfontein> #topic open floor
19:27:19 <felixfontein> anything for the open floor?
19:27:24 <andersson007_> thanks everyone
19:27:52 <gundalow> Nothing from me, apart from I'm out Mon-Wed next week
19:28:09 <felixfontein> gundalow: I guess that includes Wednesday evening?
19:28:19 <felixfontein> enjoy your ansible-free time :)
19:30:11 <felixfontein> #endmeeting