18:02:48 #startmeeting ansible_community_meeting 18:02:48 Meeting started Wed Jun 24 18:02:48 2020 UTC. 18:02:48 This meeting is logged and archived in a public location. 18:02:48 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:02:48 The meeting name has been set to 'ansible_community_meeting' 18:03:01 so, anyone around? :) 18:03:02 * samccann waves 18:03:07 hey 18:03:08 @gundalow: one thing I forgot to mention - it's useful to set up caching for pip too: https://github.com/actions/cache/blob/master/examples.md#python---pip 18:03:21 #info agenda: https://github.com/ansible/community/issues/539 18:04:17 Salutations 18:04:55 #chair andersson007_ abadger1999 18:04:55 Current chairs: abadger1999 andersson007_ felixfontein 18:05:03 hi :) 18:06:28 * acozine waves 18:06:31 I'm half-here 18:06:46 #chair acozine 18:06:46 Current chairs: abadger1999 acozine andersson007_ felixfontein 18:06:55 you'll become funiture anyway ;) 18:07:00 heh 18:07:09 #chair samccann 18:07:09 Current chairs: abadger1999 acozine andersson007_ felixfontein samccann 18:07:31 o/ 18:07:35 #chair cyberpear 18:07:35 Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein samccann 18:07:43 gundalow, you're around? 18:08:13 gundalow may be busy, I'm not sure... he pushed out a meeting we had scheduled in the morning until half an hour from now (when he shows up for that I'll remind him that we have to finish this one first ;-) 18:08:34 hehe :) 18:09:12 btw, any more comments on https://github.com/felixfontein/community.general-release/blob/master/README.md , resp. gundalow's PR: https://github.com/felixfontein/community.general-release/pull/1 ? 18:09:48 I'd really like to get this done this week (and publish it to community.general and community.network and the ansible-devel ML) 18:10:46 (also I'd like to kick it from the meeting agenda ;) ) 18:11:06 It looked good the last time I read through it. 18:11:51 #info community.general 0.2.0 and community.network 0.2.0 have been released over the weekend 18:12:00 I guess that's the most significant news since last week 18:12:14 woot! 18:12:30 Yay! 18:12:33 on the readme - is this proposed as the readme.md for community.general ? or something else? 18:12:40 these also happen to be the first two collections in ACD that actually contain a changelogs/changelog.yaml :) 18:12:44 felixfontein: what we shoud put to version_added after that? 18:12:47 felixfontein: Do you plan to make a release of community.crypto soon too? 18:12:58 samccann: no, it's about releasing/versioning for community.general and community.network 18:13:13 but you're right, the readme of community.general needs some updating 18:13:15 so where will it live eventually? 18:13:32 andersson007_: right now, 1.0.0 since that will be the next release (we said last week of july) 18:13:41 ok 18:14:12 abadger1999: I guess this or next week - I'm waiting for feedback by shaps on a proposal, and want to check something to be sure it's correct 18:15:01 samccann: good question - it will probably be a long-living issue in both collections (as written at the top), and probably also in some wiki. not sure which one though - maybe ansible-collections/overview/? or ansible/community? 18:15:05 cool 18:15:24 felixfontein: I’ll have a look tomorrow in the morning, ping me again if you don’t see anything from me 18:15:33 shaps: great, thanks a lot! :) 18:15:36 #info community.crypto will have a new release within the next two weeks 18:15:52 shaps: the url is https://github.com/ansible-collections/community.crypto/issues/74 18:16:22 I currently push for all things wiki to end up on ansible/community. 18:16:22 I wrote a propsal for releasing community.crypto: https://github.com/ansible-collections/community.crypto/issues/74 18:16:48 it's very short and simple, since a small collection like c.c doesn't need all that procedures larger collections like c.g and c.n need 18:17:10 This particular readme feels like it's a mix between a contributor guide (the changelogs etc) and a roadmap (release dates etc) 18:17:15 abadger1999: good idea! (I remember reading something like that from you(?), but there's been so much going on, I'm getting a bit confused :) ) 18:17:30 samccann: it is, kind of... 18:18:16 so jillr created a Contributing.md in their ..er.. one of the AWS collections. It makes me wonder if we should standardize on a few other files besides the readmes for this info to live. 18:19:07 I have some vague recollection that we have a default Contributing.md file for the org . . . 18:19:09 maybe Versioning.md or Releasing.md? with information on how the collection releasing works, and all related details? 18:19:20 So a roadmap might be useful as a section in the readme (since that is visible in Galaxy etc). And the contributor stuff split off into a Contributing.md file, linked to from the readme. But that assumes each collection has a different set of guidelines etc. 18:20:25 If there's a batch that will be handled in the same manner, then maybe we need one home ...like ansible/community... to hold it? dunno. I feel like docs are getting scattered to the winds a bit. 18:21:00 I guess there will be groups of collections which behave similarly (like the Supported ones); another group is community.general + community.network; and then there are lots of small collections which could do random other things (though probably most of them will be similar to f.ex. https://github.com/ansible-collections/community.crypto/issues/74) 18:21:02 So I think the long (long) run - we want the collection /docs folder to come into docs.ansible.com... is that correct abadger1999 acozine ? 18:21:39 I'd say long-term, we want the my_collection/docs folder to be visible to the user 18:21:57 oh, woops, was on another call and lost track of time 18:21:57 I think so.... at least, we know that collections will have static content that they host somewhere that we need to end up somewhere on docs.ansible.com 18:22:14 which collections actually have a /docs folder, or a /docs folder which contains something that won't be integrated in the docsite (i.e. module/plugin docs)? 18:22:18 whether that's on docs.ansible.com depends on what happens with the Galaxy roadmap and whether we can optimize the publication pipeline 18:23:56 the module/plugin docs in the Ansible-maintained collections are just a temp solution until the docs pipeline is up. Once that's ready, those particular /docs folder entries will go away. 18:24:08 Default contributing guide with GitHub will display (unless one is in the repo) https://github.com/ansible-collections/.github/blob/master/CONTRIBUTING.md 18:24:30 felixfontein: I don't know if any of them have /docs folder content today; I would like to migrate the content in the docs/docsite/rst/scenario_guides/ directory into the appropriate collections' /docs/ folders 18:24:36 "Hi! Nice to see you here!" I like that ;) 18:24:54 #chair gundalow 18:24:54 Current chairs: abadger1999 acozine andersson007_ cyberpear felixfontein gundalow samccann 18:25:20 acozine: all the 1.0.0 released collections from this week have all the module/plugin docs as rst files in their /docs folders 18:25:37 btw, how did they create these rst files? 18:25:53 did they use the docs pipeline? or something else? 18:26:17 something else with a bit of help from abadger1999 as I recall. Might be some earlier version of his code that seeded it. 18:26:28 samccann: ah, that's a good pattern, then 18:26:31 (docs web pages "edit on Github" links are broken now) 18:26:58 cyberpear: which links? modules/plugins that moved? or all of them? 18:26:59 which ones cyberpear ? 18:27:07 cyberpear: you mean from module docs in `latest`? 18:27:11 yes 18:27:19 didn't check devel 18:27:29 that is expected . . . unfortunate but I think unavoidable 18:27:40 moved ones, which is musty 18:27:50 not expected for users, though... 18:27:54 true 18:28:04 samccann felixfontein : I believe they all started with the plugin_formatter code and created their own swcript (bcoca an I were probably the main people who have worked on plugin_formatter recently) 18:28:22 I've talked to them about using antsibull-docs in the future, though. 18:28:30 good :) 18:28:39 true, and if you have a suggested workaround, we'd be happy to try it 18:28:40 otherwise we end up with 100 different tools for the same job ;) 18:28:42 ah hadn't thought about that. the edit github goes to /devel where these modules no longer exist. So do we want to point it to 2.9 instead? It breaks the idea of backporting if we do that. Otherwise we have to remove that feature entirely (at least in the older releases) 18:28:47 I need touch base with them now that the main docs pipeline is almost finished. 18:29:33 samccann: acozine: removing it for the old versions might be the best solution. it's better if the current docs (devel and soon-to-be stable-2.10) have working links I think 18:29:59 felixfontein: I think that makes sense 18:30:06 abadger1999: btw, can you update https://toshio.fedorapeople.org/ansible/docsite/ ? 18:30:15 would be nice to see how the current version looks like :) 18:31:10 felixfontein: I don't think it's changed since I published that (there are changes in the code but to support M() and seealso but I think only community.crypto is goingto take advantage of it [once a new release is made ;-)]) 18:31:48 abadger1999: there's version_added and possibly some deprecations in community.general and community.network :) 18:31:54 The DOCUMENTATION strings need to be updated with QCN in the other versions. 18:31:57 Ah, Okay :-) 18:32:03 I'll try to make an update today :-) 18:32:04 but yep, the other things are still missing 18:32:08 cool, thanks! 18:32:29 ok. should we continue a bit through the agenda? 18:32:46 yes please, I have some questions about hte ansible package that need decisions. 18:32:47 there are some topics by cyberpear 18:33:04 I still think the FQCN should be auto-filled by tooling 18:33:04 though I'm not sure how much we can say about that right now 18:33:11 in the docs and elsewhere 18:33:19 maybe we should start with the most pressing things first, i.e. the questions by abadger1999? 18:34:08 go ahead with cyberpear's three. 18:34:16 #info https://github.com/ansible/community/issues/539#issuecomment-634846106 18:34:33 #info first topic: glossary of terms in the New World Order (and simplification/deconflict as appropriate) ACD, ansible-base, ansible-core, etc 18:34:52 right now we have https://github.com/ansible-collections/overview/#terminology 18:34:58 * cyberpear happy to defer these if there are more pressing items 18:35:17 and maybe some more pages where some terms are explained? 18:35:45 that page is missing `ADC/"Ansible"` 18:35:51 I'd like to definitely defer topics 2 and 3 from that list, because I don't think we can answer them here - I think they are more for the core team 18:35:55 *ACD/Ansible 18:36:00 ACD doesn't exist anymore 18:36:00 as I recall, there is 'something' in sphinx that supports a glossary - so at some point we should move the defined list there. 18:36:17 I'm mainly using it as a placeholder for Ansible, to make more clear that I don't mean what's now called ansible-base 18:36:37 i've trakced some of the updated needed to overview/README in https://github.com/ansible-collections/overview/pull/82 some of that was based on cyberpear's feedback 18:36:38 well, I think we should spell out that "Ansible" means ansible-base plus everythnig in the accepted community collections 18:36:47 ` mention ACD as that term has been used, though make it clear that's not a term we should be using anymore` 18:37:00 for example 18:37:02 * cyberpear forgot about that PR 18:37:33 * gundalow notes 23 days ago, looks like I forgot about it as well 18:37:37 samccann: (yeah: :term:`term label` Forms a link to a special section in glossary.rst.) 18:37:59 gundalow: so what does the term "Ansible" mean? the PR only explains "``ansible``" :) 18:38:09 I guess some/all of this should also end up in https://docs.ansible.com/ansible/latest/reference_appendices/glossary.html ? 18:38:25 felixfontein: stop asking difficult questions :P 18:38:40 hehe :) 18:38:43 Ansible can mean whatever you want it to, and that's part of the problem 18:38:54 yep, I think that is a good location 18:39:14 May need changing to "The `ansible` package", "the Ansible Project", "The Ansible language", etc 18:39:34 "ansible" as a single word is too ambiguous 18:39:37 I wrote a summary of "what `pip install ansible` means" within the last week . . . somewhere 18:40:00 maybe this is something that should be better discussed in the docs meeting? like where to collect and combine these things? 18:40:01 * acozine digs around to find it 18:40:11 felixfontein: yup, maybe 18:40:25 though if anyone has feedback, feel free to add it on PR#82 18:40:28 (back in 5) 18:40:29 not that the docs meetings currently are less filled though ;) 18:40:38 I think I currently say Ansible-2.10+ to differentiate it from classic ansible. The definition of ansible-2.10 would be something like a collection of ansible-base plus some community collections that attempts to give a user experience similar to ansible-2.9 and earlier. 18:40:49 well, we need a term that means "traditional kitchen sink ansible" 18:41:07 cyberpear: that's Classic Ansible according to the overview 18:41:09 with collections included 18:41:38 CA only applies to 2.9 though? 18:41:41 Yeah, that's what I call ansible-2.10+. We could also call it the ansible package I think. 18:41:53 I think it applies to 2.9 and before 18:42:09 ACD was a terrible name, but at least it was comprehensible 18:42:11 yeah, CA means 2.9 and before. 18:42:14 hehe :-) 18:42:52 I'm still for ACDC. but I guess RH legal won't be happy at all ;) 18:43:00 If we do things correctly.... the end user experience should be nearly the same for the ansible package in 2.9 and in 2.10. 18:43:16 So I guess we don't really need an end user term... but we do need a developer term. 18:43:25 yes 18:43:29 Since from the dev standpoint, things are very different in 2.10+ 18:43:30 i created tracking issues for edit on github and the glossary - on ansible/ansible. 18:43:39 samccann: cool! 18:43:45 I can add them to the docs WG agenda as well if that helps move it off the plate today 18:43:57 cyberpear: what do you think? 18:44:42 even end users hitting the "edit on github" link is a change to them 18:44:53 (back) 18:45:04 wb gundalow 18:45:25 Just say ansible now and say classic ansible for 2.9 or less? (muscle memory won't work well), ansible-2.10+ as the new, temporary term until no one remembers classic ansible anymore? 18:46:04 abadger1999: sounds good to me 18:46:06 we should, in theory, eventually be able to reinstate the edit on github links to module docs, once those are published under the collections "tree" 18:46:41 (not sure if we can convince everyone though) 18:47:10 the antonym of classic is modern.... "modern ansible" for 2.10+? 18:47:41 "ansible is still ansible, just it's been fragemented across 25 repos. Use it the same as you always have, except new modules have painfully-long names"? 18:47:49 hmm, I like that term, but it is too easy to get wrong if you don't know that we defined it this way 18:47:56 afiak, the edit on github has only one option right now. It may take someone with coding skills to find a way to support multiple repos. 18:48:10 cyberpear: heh. Yeah. (Old modules have the same, short names, though) 18:48:11 cyberpear: > 60 18:48:30 cyberpear: closer to 60 18:48:39 * gundalow hifives felixfontein 18:48:59 * felixfontein hifives gundalow 18:49:32 yeah, >60 doesn't help the case... 18:49:37 ok, maybe some homework ;) how about everyone thinks about a good new name for ACD that isn't too easily confused / misused? 18:49:55 (from purely an end-user perspective, the most annoying part will be the annoyingly-long module names) 18:50:22 cyberpear: when you use the `collections:` keyword, it shouldn't be that bad 18:50:49 does `collections:` work in a role `meta/main.yml`? 18:50:50 afaik, within docs, We have to call ACD Ansible. I think that came from On High so to speak 18:50:56 (sorry, drifting off-topic..) 18:50:57 #info homework: everyone should think about a good new name for ACD that isn't too easily confused / misused 18:51:12 cyberpear: I think so, I've never used it yet ;) 18:51:25 see my comment above. y'all can call it something else, but I think we have to call it Ansible in the docs. 18:51:31 18:51:38 I seem to remember trying it and it failing, but maybe that was too long ago 18:51:55 #info glossary will get updated eventually, discussions will happen mostly in the docs meeting 18:51:58 So probably it *is* desirable that whatever we call it turns into "Ansible" in a few releases. 18:52:40 #info end user docs needs to refer to ansible-2.10+ as "ansible" . 18:53:06 do you all want to continue discussing this now? I'm not sure we will get many new insights now... 18:53:06 cyberpear: It did not at one time; I don't know if that's changed. 18:53:20 I think we should table it. 18:53:34 * cyberpear happy to move on to others' topics 18:53:36 is that fine for everyone? (if not, complain fast ;) ) 18:53:47 cyberpear: Does that glossary pointed out earlier address the rest of the potential terminology? 18:53:49 #topic https://github.com/ansible/community/issues/539#issuecomment-638230501 18:54:08 next topic: backwards compatibility of ansible (as in ACD) releases 18:54:13 Okay. 18:54:19 So for this topic. 18:54:35 https://github.com/ansible-community/antsibull/issues/70 18:54:51 #info Writeup of the problem and potential solutions: https://github.com/ansible-community/antsibull/issues/70 18:55:21 I'm relying on semantic versions for whether to update a collection in a minor release of ansible. 18:55:58 So in the easy case, ansible-2.10.0 ships with community.general-2.0.0... ansible-2.10.1 could ship with community.general-2.3.5 18:55:58 right now, there are still a lot of collections that haven't reached 1.0.0 yet 18:56:12 But there's a cornercase I'm not sure what to do with... 18:56:35 if a collection hasn't reached 1.0.0 yet, then the semantic version spec basically says, the author can do whatever they want. 18:56:36 for the 0.y.z case, maybe only pull changes when specifically requested by the maintainer 18:56:56 and get "certification" from the maintainer that it's a non-breaking change 18:57:06 is it possible to say a collection has to be 1.0.0 before it can be included in ansible? 18:57:11 So if ansible-2.10.0 ships with community.crypto-0.1.0.... what do we want to be legal in ansible-2.10.0? 18:57:45 samccann: "what can be included in ansible?" is a question that's been deferred until past the 2.10 release, but is very important, IMO 18:57:53 heh 18:58:16 (I've brought it up multipl etimes, and everyone says, nothing new in 2.10) 18:58:17 does `proposal 5` mean that a) collection owners need to know this is a thing b) Need to be reminded (in advance) of upcoming deadlines? That's all OK, just something I wanted to understand and check 18:58:20 I don't think so because then we'd have to either (1) hold ansible-2.10.0 until all the collections hit 0.1.0 or we'd need to decide that ansible-2.10.0 won't attempt to ship all the modules that were in ansible-2.9. 18:58:28 cyberpear: that's no 5 in https://github.com/ansible-community/antsibull/issues/70, and also what I prefer :) 18:59:18 felixfontein: that seems like the best option, yes 18:59:34 (the latter *might* be a lost cause, though... I don't attempt to validate that the version of the collection I ship in ansible actually contains all of the modules that were in 2.9... A collection owner could have removed and renamed and etc prior to the colection version I include.) 18:59:36 I'm still hoping that in a month or so, all collections will have 1.0.0 released, or are very close to it 18:59:49 (c.g and c.n will be releasing 1.0.0 around then) 19:00:10 cyberpear: (and there is a loophole... there can be new content in existing collections but not a collection with 100% new content). 19:00:35 indeed, an annoyance, but we'll get 2.10 out the door and can finally tackle the question 19:00:47 samccann: (Your idea is Option (2) on the antsicull ticket I linked, by the way) 19:00:52 cyberpear: Yeah :-) 19:01:01 felixfontein: I'm assuming it's on my todo list to chase them. That's partly what I was thinking as part of `I think we (I?) need to come up with a checklist for all the collections in https://github.com/ansible-community/ansible-build-data/blob/main/2.10/acd.in off the top of my head they have `ansible-test sanity` run & passing on stable-2.10, is galaxy.yml correct (whatever that means), is it versioned correctly, feature 19:01:01 freeze, etc, etc` just before the meeting started 19:01:05 antsicull, that's a nice typo :) 19:01:16 (when talking about maybe even throwing out collections) 19:01:34 heh 19:01:47 gundalow: yes :) 19:01:52 Heh... Freudian? ;-) 19:01:58 abadger1999: definitely! 19:03:09 #info gundalow's todo list contains chasing ansible (as in ACD) collection owners to make sure they have a proper (as in: pass sanity checks, galaxy.yml correct, versioned correctly, etc.) release out "soon" (or not too late) 19:03:24 I think 4 or 5 seems the best to me. 19:03:40 Something that is end-user focused but still allows updates. 19:04:20 how about first sticking to 5, and discuss switching to 4 say in a month if it is clear that there are too many collections which haven't reached the 1.0.0? 19:04:23 4 would be reasonable to me, but then folks need to know we're imposing semver rules where they didn't exist before 19:04:27 I think 5 will be manual intervention by both the ansible release manager and by collection owners but that's not the end of the world. 19:05:33 4 is going to let through mistakes but I'm not sure if that's the end of the world for end users either. 19:05:39 I'd like to minimize manual interventions 19:05:53 (also, any semver version w/ a dash at the end doesn't have to follow any rules, either, as these are considered pre-releases) 19:06:02 1.0.0-alpha1 for example 19:06:08 Most people instinctively follow something like that... but there will always be someone who doesn't. 19:06:22 cyberpear: I guess we won't include pre-releases? (except in pre-release ansible releases?) 19:06:23 Ooohh.... I did not realize that. 19:06:48 I'll have to check how the library I'm using to compare semvers deals with that. 19:07:39 #action abadger1999 to open a ticket to explore how prereleases liek community.general-2.10.0-rc1 get sorted in the semver library we're using 19:08:02 they should get /sorted/ earlier than the non-dashed version 19:08:04 per the semver spec 19:08:24 so 2.10.0-(anything) is an earlier version than 2.10.0 19:08:36 I think the library is doing that (last time I checked) 19:08:48 Does anyone favor something other than option 4 or 5 from the ticket? (samccann, specifically highlighting you since you had asked whether option 2 was doable) 19:09:02 we'd need to make sure that we don't use pre-releases of collections in final releases though 19:10:00 #action abadger1999 to also figure out if we can exclude prereleases from the ansible final releases. 19:10:07 I'm okay with 4/5 if we can't get collections to 1.0.0. We should decide on what happens in 2.11 though (as in will we always allow not-quite-ready collections in Ansible or will there be a point where it has to at least be a 1.x ) 19:10:09 if you favor something else, please write so quickly (and add the long explaination afterwards) 19:10:25 And then it will be poll time! 19:10:32 I agree, no pre-released collections (with a dash) in an ansible release 19:10:39 samccann: I think for collections with completely new content, we can ask that they release 1.0.0 before including them in the future 19:10:47 should be fine in an ansible pre-release, though 19:11:43 POLL: do you prefer (4) or (5) from https://github.com/ansible-community/antsibull/issues/70? 19:11:52 5 19:11:53 (I hope that's the right question :) ) 19:11:58 5 19:12:01 Alright: poll time... do you favor Option 4 (automatically upgrade when z bumps in a version like 0.y.z) or Options 5 (Allow upgrades in 0.y.z but make the collection owner request it manually) 19:12:15 Sorry ;-) I'm late to the party. 19:12:18 5 19:12:23 5 19:12:24 sorry for shortcutting you, wasn't sure whether you are typing or waiting ;) 19:12:47 No worries :-) 19:12:57 Cool, If no one else.... 19:13:02 I'll implement 5. 19:13:04 ...looks like 5 it is 19:13:08 great :) 19:13:31 #info we decided on option 5: allow upgrades in 0.y.z, but collection owner must request that manually 19:13:51 #info goal is still to have 1.0.0 or newer for every collection 19:14:03 Cool. 19:14:04 okey 19:14:17 5 ( I think) 19:14:52 next topic would be https://github.com/ansible/community/issues/539#issuecomment-643453336 19:15:15 do you want to continue discussing (we're already in overtime), or should we continue next week? 19:16:26 next time 19:16:31 Okay, fine by me. 19:16:43 fine either way 19:17:24 andersson007_ left some time ago btw 19:17:39 so maybe let's think about this as homework, and continue next week? 19:17:55 Sound good. 19:18:00 I think this is something that isn't super urgent, so next week should be fine too 19:18:20 (about the question: I prefer what we're doing now btw ;) ) 19:18:40 yeah, not super urgent especially if we decide nothing needs to change ;-) 19:20:08 true ;) 19:20:21 Is there anywhere else we should be pinging out these questions, or others we should be asking? 19:20:37 Do we need to @mention all Collection owners on these things? 19:20:54 hmm, good question 19:21:00 collection owners need to know. They may want a say in them... Do we have a way to get in touch with them all? 19:21:00 and/or promote/@mention this meeting 19:21:41 I feel like this meeting needs someone from the ansible-maintained collections team to keep an eye on what's happening that might impact what they are doing 19:22:06 samccann: some people from Ifty's teams? 19:22:13 at least one yeah 19:22:28 I try to bring back what I learn, but it probably gets mangled along the way 19:22:34 btw, updated ansible (as in ACD) changelog: https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f 19:22:39 ...or forgotten :-) 19:22:42 #action gundalow to ensure that some people from Ifty's team are aware and attend this meeting 19:23:39 woot!! 19:23:40 who is Ifty? 19:24:00 (I'm bad with names, and I guess this is one I haven't heard often enough to recognize...) 19:24:09 internal Ansible manager 19:24:11 I assumed it was a typo of lyft until I saw it repeated multiple times ;) 19:24:15 ah 19:24:42 ok 19:24:51 I guess we can end the meeting then? 19:25:05 (probably should have done that ~10 mins ago) 19:25:09 :-) 19:25:12 #endmeeting