19:02:52 <Rhea> #startmeeting Fedora DotNet (2017-02-28) 19:02:52 <zodbot> Meeting started Tue Feb 28 19:02:52 2017 UTC. The chair is Rhea. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:02:52 <zodbot> The meeting name has been set to 'fedora_dotnet_(2017-02-28)' 19:02:55 <Rhea> #meetingname dotnet 19:02:55 <zodbot> The meeting name has been set to 'dotnet' 19:02:57 <Rhea> #nick dotnet 19:03:02 <Rhea> #link https://fedoraproject.org/wiki/Meeting:DotNet_2017-02-28 19:03:10 <Rhea> #undo 19:03:10 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x121d1350> 19:03:18 <Rhea> #topic Agenda 19:03:22 <Rhea> #link https://fedoraproject.org/wiki/Meeting:DotNet_2017-02-28 19:03:24 <Rhea> #info (1) Roll Call 19:03:28 <Rhea> #info (2) Announcements 19:03:30 <Rhea> #info (3) Action items and Tickets 19:03:33 <Rhea> #info (4) Packaging progress 19:03:34 <Rhea> #info (5) Open Floor 19:03:38 <Rhea> #topic Roll Call 19:03:40 <Rhea> #info Name; Timezone; Sub-projects/Interest Areas 19:03:43 <Rhea> #action dotnet New members, make sure you introduce yourself on the DotNet mailing list [ https://fedoraproject.org/wiki/SIGs/DotNet ] 19:03:48 <Rhea> If this is your first time at a DotNet meeting, feel free to introduce yourself to everyone and say hello! If anyone has any questions before we get started with the rest of the agenda, now is also a good time to ask. 19:03:56 <Rhea> .hello rhea 19:03:57 <zodbot> Rhea: rhea 'Radka Janek' <radka.janek@redhat.com> 19:03:58 <Rhea> #info Radka Janek; UTC+1; CommOps, Diversity, DotNet,... 19:04:31 <bt_0003> First time here (bryan) - hello everyone 19:04:34 <nmilosev> .fas nmilosev 19:04:39 <zodbot> nmilosev: nmilosev 'Nemanja Milosevic' <nmilosevnm@gmail.com> 19:04:41 <nmilosev> Hello bt_0003 and welcome! :) 19:04:43 <pcreech> .hello pcreech 19:04:44 <zodbot> pcreech: Sorry, but you don't exist 19:04:47 <pcreech> .hello pcreech17 19:04:48 <zodbot> pcreech: pcreech17 'Patrick Creech' <pcreech@redhat.com> 19:05:04 <amitosh> #info Amitosh Swain; UTC+5:30; DotNet, Go, Docker, Python 19:05:40 <Rhea> pcreech you don't exist :< 19:05:44 <tmds> hi all 19:05:50 <amitosh> hello 19:05:54 <pcreech> Rhea: lol... difference btw nick and fas :( 19:05:59 <tmds> meeting started already? 19:06:01 * nmilosev o/ tmds 19:06:02 <Rhea> rip 19:06:08 <Rhea> just about tmds 19:06:20 <Rhea> #topic Announcements 19:06:47 <Rhea> What's new.. hmm... nothing? 19:07:06 <nmilosev> F26 builds live :) 19:07:13 <tmds> nice 19:07:23 <Rhea> but that's'not new, is it? i have messy time perception 19:07:33 <Rhea> I mean since last week 19:07:34 <Rhea> :D 19:07:37 <nmilosev> Yeah :D 19:07:43 <nmilosev> last week in fedora is ancient history 19:07:45 <tmds> nmilosev: have you tried building the source-build? 19:08:04 <nmilosev> tmds, sadly no, didn't have much time for it - still only works on F23 19:08:32 <Rhea> #topic Action items and Tickets 19:08:32 <tmds> ok, haven't tried it myself either 19:08:47 <Rhea> #link https://meetbot.fedoraproject.org/fedora-meeting/2017-02-21/dotnet.2017-02-21-19.12.html 19:08:51 <nmilosev> tmds, we can work on it together, feel free to ping me :) 19:08:55 <Rhea> #link https://pagure.io/fedora-dotnet/issues?tags=meeting 19:08:59 <Rhea> #info How This Works: We look at past #action items from the last meeting for quick follow-up. If a task is completed, we move on to the next one. If it isn't, we get an update and re-action it if needed. If no status, we'll try to get a quick update and move forward. 19:09:02 <tmds> nmilosev: subscribe to this one: https://github.com/dotnet/cli/issues/5854 19:09:11 <Rhea> #info === Ticket #5 === 19:09:19 <Rhea> #info === "wiki pages" === 19:09:21 <Rhea> #link https://pagure.io/fedora-dotnet/issue/5 19:09:28 <Rhea> #info I've done some gardening, please provide feedback and ideas for improvement in the ticket. 19:10:35 <Rhea> About that, I do not think, that we need to write anything other than what it has there... 19:10:59 <Rhea> It has references to both copr / microsoft for packages, which in turn has info about installing it 19:11:14 <Rhea> I included that asp.net microsoft training 19:11:18 <nmilosev> Hey Rhea, should I make nmilosev/dotnet-sig 19:11:24 <nmilosev> or it's fine like this? 19:11:31 <nmilosev> (for now) 19:11:43 <Rhea> that we discussed already last time o.o 19:12:01 <nmilosev> oh 19:12:02 <nmilosev> sorry 19:12:05 <Rhea> I would like to see *all* the repositories deleted to prevent confusion, and have but one... 19:12:28 <nmilosev> Since we already have all the links in place, maybe it's better to just delete the old ones 19:12:31 <nmilosev> and leave dotnet-clean 19:12:52 <Rhea> "dotnet-clean" is not very professional name is it :P 19:13:24 <tmds> it's better than dotnet-dirty :D 19:13:34 <nmilosev> :D 19:13:44 <nmilosev> Okay I will move to dotnet-sig or just dotnet 19:13:49 <tmds> just dotnet 19:13:56 <tmds> should there be a version number in it? 19:14:04 <tmds> or is that a level underneath? 19:14:07 <Rhea> It should be something either generic, or dotnet-sig, to signify that it's maintained by this team / a team / 19:14:34 <nmilosev> tmds, we can provide multiple packages in the same repo 19:14:42 <nmilosev> Rhea, then dotnet-sig :) 19:15:24 <Rhea> Yup I would be for having one repository with multiple packages (1.0/1.1/2.0) 19:15:30 <pcreech> +1 19:15:53 <Rhea> naming would be just dotnet-version... 19:16:15 <Rhea> while `dotnet` would always point to the highest? 19:16:30 <nmilosev> yes 19:16:31 <tmds> omajid: hi 19:16:43 <omajid> hi! 19:16:47 * nmilosev o/ omajid 19:16:48 <Rhea> oh hi 19:16:58 <tmds> we are discussing the hardest thing in software: naming things 19:17:01 <omajid> sorry for being late. 19:17:12 <tmds> and versioning them ... 19:17:26 <nmilosev> http://core0.staticworld.net/images/idge/imported/article/itw/2013/10/23/programmers_hardest_tasks-600x700-100521914-orig.jpg 19:18:34 <Rhea> #idea Single copr repository with multiple packages following the dotnet-version naming - e.g. dotnet-1.0 dotnet-1.1 which would always be the latest (ie 1.0.4 / whatever) 19:18:40 <tmds> nmilosev: https://martinfowler.com/bliki/TwoHardThings.html 19:19:19 <nmilosev> Rhea, I can see a couple of issues though 19:19:25 <nmilosev> We can't have 1.0 and 1.1 side by side 19:19:30 <omajid> i like this idea. but dotnet iteslf wants `dotnet` to do the version selection. what package would provide the `dotnet` binary? 19:19:48 <omajid> nmilosev: we can't? why? 19:19:50 <nmilosev> ideally, cli and framework should be separated in the future 19:20:01 <nmilosev> omajid, the way we have it now, I mean 19:20:12 <Rhea> Well we are back in the begining then 19:20:13 <nmilosev> /usr/bin/dotnet for example would be a conflict 19:20:45 <nmilosev> shared framework is going to be fine, since it is just one directory 19:20:49 <omajid> nmilosev: we could just have /usr/bin/dotnet-1.0 and /usr/bin/dotnet-1.1 symlinked to /usr/lib/dotnetcore/whatever/bin 19:21:06 <nmilosev> omajid, yes that's a nice workaround :) 19:21:10 <amitosh> omajid: +1 on this 19:21:25 <nmilosev> we currently don't have 1.0 packages, that is also an issue 19:21:32 <Rhea> yup 19:21:32 <nmilosev> for example for using EF tools 19:21:35 <nmilosev> you need it 19:21:53 <Rhea> it's not an issue, i don't think we need 1.0 packages... 19:22:03 <Rhea> we start packaging with the version at hand when we are ready 19:22:10 <Rhea> screw the old ones 19:22:17 <Rhea> =) 19:22:35 <omajid> nmilosev: but i think (don't know for sure) .net upstream wants a /usr/lib/dotnetcore/dotnet that's shared across versions. it's supposed to be a tiny binary that finds a real dotnet (host?) to run. 19:23:35 <nmilosev> omajid, in the 2.0 nightly there is already an option to specify framework version when creating a new app for example :) 19:23:48 <nmilosev> so: dotnet new -f netcoreapp1.0 19:24:31 <tmds> nmilosev: how do you get the 1.0 runtime? 19:25:34 <nmilosev> for now, the ugly way: unpack it from microsoft tar.gz to /usr/lib64/dotnetcore/shared/Microsoft.NETCore.App/ 19:25:39 <nmilosev> like you showed me :D 19:26:01 <amitosh> but which package will provide '/usr/lib/dotnetcore/dotnet' ? For instance,if i have 2.0 and then 2.1 lands? 19:26:13 <tmds> omajid: indeed, the idea is there is one dotnet binary 19:26:29 <nmilosev> ideally sdk (cli) would be separate 19:26:41 <nmilosev> and frameworks would be separate also 19:26:51 <nmilosev> So you install cli, and whatever frameworks you want 19:27:26 <Rhea> Can you guys explain to me why do we have frameworks? 19:27:42 <Rhea> I mean... if we can publish for whatever platform we want and don't need any framework there... 19:27:48 <Rhea> why would we still bother again? 19:27:53 <nmilosev> Rhea, one use case is to run app compiled for older framework 19:27:59 <tmds> frameworks are the different versions of .net, like we have .net 2.0 and .net 4.5.2 19:28:00 <Rhea> ...With separate runtime packages and sh... 19:28:35 <Rhea> Yeah but... why would someone publish their app without including all the necessary nonsense with it? 19:28:45 <tmds> on windows, a .net 2.0 app from the old days will also use the .net 2.0 framework 19:28:46 <Rhea> publish/build/whatever? 19:29:05 <nmilosev> Rhea, not sure, but entity framework tooling is this way 19:29:10 <nmilosev> only works with 1.0 19:29:10 <omajid> microsoft had a request for us. for packaging (like in this case) we should start a discusion upstream about what we plan to package and how we plan to do it and what issues we expect. so they can try and accomodate us and/or point out what we are doing wrong and/or fix things that are broken 19:29:12 <Rhea> What I mean is that we do not -need- runtime framework anymore... 19:30:16 <omajid> we have two options: publish standlone (doesn't need runtime) and publish targetting a framework (needs runtime) 19:30:39 <Rhea> Exactly, why do we still have the 2nd option? 19:30:46 <Rhea> Is it to save 50MBs? 19:31:12 <omajid> couple of reasons, i think. one is bundling/static linking (see fedora's packaging opinion on that) 19:31:16 <omajid> disk space is another 19:31:33 <Rhea> hmm 19:31:35 <omajid> https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries 19:31:57 <Rhea> I don't'really mean we as fedora, i mean we as dotnet 19:32:31 <omajid> suppose a security fix happens in dotnet. option 2 allows someone to update their dotnet version and magically all programs using it are fixed. 19:32:31 <tmds> .net applications that come with the distro should rely on a runtime provided by the distro 19:32:45 <Rhea> Back on the original topic... In this case we should probably name it in a dotnet-sdk-1.0 way 19:32:53 <Rhea> and then in the future dotnet-runtime-whatever 19:32:54 <tmds> .net applications that do not come with the distro should preferably use the linux-x64 rid 19:33:01 <tmds> and publish standalone 19:33:04 <tmds> that's my take on it 19:33:44 <Rhea> Or to follow better conventions... dotnet-devel-1.0 ? 19:33:46 <omajid> we should look at how other languages do it. 19:33:56 <tmds> I am not a fan of the rid graph and distro specific packages being published by microsoft to nuget 19:34:37 <tmds> I don't think it is possible to include fixes in the fedora build of dotnet, and ensure someone else that publishes for fedora has those fixes 19:34:59 <tmds> the other guy will pull the runtime from nuget, and it will be built by microsoft, and won't have the fixes 19:35:02 <nmilosev> yes, that's really big issue 19:35:24 <nmilosev> we should stay close as much as possible to linux-x64 in my opinion 19:35:25 <Rhea> Well we need to always go upstream, we should NEVER have "our own fork" 19:35:47 <tmds> microsoft should think about where they see their responsability and where they see that of the distros 19:36:01 <tmds> now they are just building stuff 19:36:08 <Rhea> They should not have any when it comes to distro specific stuff imho 19:36:17 <Rhea> I mean ... dude it's my job 19:36:21 <Rhea> xD 19:36:26 <tmds> that's not how it works now 19:36:30 <Rhea> yup 19:36:32 <tmds> your distro needs to be in a graph 19:37:17 <omajid> they told me multiple times "you can add your distro's runtime id to any nuget package and it should be picked up by dotnet" 19:37:21 <Rhea> But hey, as far as current workflow goes, we should not have anything specific to fedora locally, we should always push it upstream 19:38:29 <omajid> but there's going to be a lag between fix-in-fedora and fix-in-upstream-fedora-nuget 19:38:30 <tmds> omajid: I read that too, some guidelines and a unified approach for all distros would be nice 19:39:10 <tmds> it is always the goal to be close to the upstream but the practice often requires some patching 19:39:39 <Rhea> indeed 19:40:07 <Rhea> So we went off topic by far, can we please finish the naming topic? 19:40:14 <Rhea> What are we naming our packages 19:40:33 <Rhea> thebestsdkforcsharp-1.1 or what 19:41:30 <Rhea> We should have all of them available (well, say 1.1 and higher) 19:41:55 <Rhea> Now we could have them as `dotnet` be the highest version available 19:42:07 <Rhea> then lower versions could be specific `dotnet-1.1` etc 19:42:24 <nmilosev> or compat-dotnet 19:42:28 <Rhea> When installing it, only one of them could be up at the time 19:42:44 <omajid> i think we should ask for upstream's guidance here. see what they have to say. python upstream, for example, suggests python == python2 19:42:49 <Rhea> sdk-wise, i believe, we can only have one 19:43:04 <tmds> you can have multiple sdks too 19:43:12 <Rhea> Yeah but is there a reason to? 19:43:30 <tmds> you might like the dotnet new options better on the other sdk :D 19:43:31 <Rhea> If you can target whatever version you want from your highest sdk 19:44:22 <omajid> tmds: oh, there's a way to say 'run dotnet new, but the way 1.0 runs dotnet new'? 19:44:56 <omajid> otherwise, what does multiple sdk mean/look like in practice? 19:45:07 <Rhea> hmm 19:45:23 <tmds> I haven't tried it, but I believe you can specify the sdk version in global.json and that will direct the dotnet binary to a specific sdk 19:46:21 <nmilosev> tmds, that's only for .sln? 19:46:35 <nmilosev> (which you can't create with dotnet new 1.1) 19:46:40 <nmilosev> :D 19:46:44 <tmds> no global.json 19:46:57 <tmds> let's google 19:47:10 <tmds> https://docs.microsoft.com/en-us/dotnet/articles/core/tools/global-json 19:47:19 <Rhea> hmm 19:47:52 <tmds> and for msbuild, only the sdk property will remain: https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/tools/global-json 19:48:01 <nmilosev> The global.json file is used on .NET Core projects to define the solution metadata. 19:48:07 <nmilosev> _solution_ 19:48:19 <tmds> nmilosev: "owever, its main purpose is not to define solution metadata as in previous releases, but to allow selection of the CLI version being used through the sdk property." 19:48:19 <nmilosev> which you can't create as far as I know without Visual Studio 19:48:47 <nmilosev> for existing projects, it should work :) 19:49:05 <Rhea> Imagine there are different packages for these... dotnet-sdk-1.0 -> requires -> dotnet-runtime-1.0 ? Then... dotnet-sdk-1.1 -> requires dotnet-runtime-1.0 AND dotnet-runtime-1.1 ??? 19:49:22 <Rhea> (assume versions grow evenly) 19:50:03 <tmds> yes, an sdk may support multiple frameworks, but it may also require multiple frameworks to work 19:50:07 <tmds> ideally it should only need one 19:50:28 <Rhea> yeah, well, i guess that we would cross that bridge when we get to it 19:50:39 <Rhea> for now though, are we happy with calling it dotnet-sdk-1.1 19:50:44 <Rhea> the package we've got right now 19:51:18 <omajid> nmilosev: the upcoming release can create solutions: https://www.hanselman.com/blog/TryingOutDotnetNewTemplateUpdatesAndCsprojWithVS2017.aspx 19:51:28 <Rhea> omajid: was there already place for the discussion about packaging you mentioned, or shall we spark it? 19:51:41 <omajid> Rhea: not that i know of. lets start a new one. 19:51:54 <Rhea> Kay, we can get to that after the meeting 19:52:02 <Rhea> Now the name, dotnet-sdk-1.1 19:52:05 <amitosh> if dotnet-sdk-m.n needs dotnet-(m-1).(n-1) that could be huge 19:52:33 <omajid> amitosh: can you define "need" in this context? 19:52:50 <amitosh> omajid: dependency 19:52:56 <Rhea> like what i asked about sdk 1.1 requiring both 1.0 framework and 1.1 framework 19:53:20 <amitosh> Rhea: yes 19:53:39 <Rhea> it should probably require only it's latest, where it's'optional to install another to be able to target it, don't'think it will go that well tho 19:53:53 <omajid> fun fact: the upcoming sdk (call it tools 1.0) requires 1.1 framework. so if you want to target 1.0, you need 1.0 framework and 1.1 framework and the tools installed 19:54:12 <Rhea> yup 19:54:23 <Rhea> but it doesn't -require- 1.0 framework 19:54:29 <Rhea> you just need it to use it 19:54:33 <Rhea> correct? 19:54:47 <Rhea> would spit out errors if you would try to use it while you wouldnt have it i assume 19:54:58 <tmds> yes, that you are missing the runtime 19:55:07 * omajid hasn't checked 19:55:26 <tmds> like global.json tells dotnet which sdk to use 19:55:35 <Rhea> hmm 19:55:39 <tmds> there is a *.runtime.config.json that tells dotnet which framework to use 19:56:01 <Rhea> so anyway, the naming... 19:56:03 <tmds> for example if you have a look in the sdk folder, there will be a runtimeconfig for the c sharp compiler and one for the sdk dotnet 19:56:18 <tmds> csc.runtime.config and dotnet.runtime.config 19:56:27 <Rhea> for our current package, what do we want to call it... just dotnet-1.1 until it is separated for sdk/runtime? 19:56:57 <Rhea> And after it's separate, go with dotnet-sdk and dotnet-runtime ? 19:57:16 <tmds> I prefer to drop the runtime suffix 19:57:29 * omajid doesnt' have an opinion. thinks we should ping upstream first 19:57:58 <tmds> or not 19:58:11 <tmds> actually, people will install the sdk 19:58:17 <omajid> i am also thinking that it should be dotnet core, not dotnet to distinguish this from .net framework 19:58:19 <tmds> the runtime will come as a dependency of packages 19:58:32 <tmds> so the sdk should have an easy name, runtime can include runtime 19:58:40 <Rhea> netframework is dead tho 19:58:46 <Rhea> and wont be present in linux packages 19:58:52 <omajid> not for gui applications, not yet. 19:59:06 <omajid> yeah, there's no .netframework for linux. 19:59:35 <omajid> even still, we don't call mysql server sql-server because there's no sql server on linux ;) 19:59:56 <omajid> anyway, i am okay with whatever others want. 20:00:22 <tmds> is ms calling it "dotnet" everywhere? 20:00:37 <tmds> I think so, and the executable is also named dotnet 20:00:41 <tmds> so that's a good name 20:00:57 <omajid> https://www.microsoft.com/net/download still says .net framework vs .net core vs xamarin 20:01:12 <tmds> I mean, like package names for ubuntu etc 20:01:37 <Rhea> cli binary is dotnet as well 20:01:47 * Rhea shrugs 20:02:14 <omajid> oh. https://github.com/dotnet/core-setup/blob/master/README.md 20:02:20 <omajid> it's dotnet- 20:02:41 <omajid> dotnet-host, dotnet-hostfxr, dotnet-sharedframework 20:05:25 <Rhea> So the ticket for github would have... 1) Our idea of versioning packages: a) present time/near future: dotnet-major.minor packages that can be installed at the same time, with `dotnet` being simlink to the highest version. 20:05:32 <Rhea> Correct? 20:06:47 <tmds> dotnet is not a simlink 20:06:58 <tmds> dotnet is the dotnet-host 20:07:07 <Rhea> Question omajid what's the difference between host and hostfxr - is the resolver the thing that specifies which thing we are using? 20:07:23 <Rhea> (all the things) 20:07:43 <omajid> Rhea: some others: what do multiple packages look like (on disk and naming). are multiple sdks in parallel supported? 20:07:55 <tmds> the dotnet-host is the binary that you call, the hostfxr is a library that is per version which contains the policy to select the appropriate shared framework 20:07:55 <omajid> Rhea: sorry, not sure 20:08:08 <Rhea> I see 20:08:26 <Rhea> So based on that, comes the answer 20:09:09 <Rhea> so dotnet-host is dotnet-sdk? 20:09:12 <Rhea> xD 20:09:25 <Rhea> no wait the other way around 20:09:27 <tmds> so users want to install sdks, and applications want to depend on runtimes, sdks depend on runtimes, runtimes depend on the host 20:09:38 <omajid> can we ask "what are the components" in the ticket? ;) 20:09:53 <Rhea> ^ 20:10:18 <Rhea> Ticket: Linux Packaging 20:10:30 <Rhea> a) what are we packaging? 20:10:35 <Rhea> b) how do we call it? 20:10:36 <tmds> perhaps an open ended question is best: how should we package .net core for our distro 20:10:40 <Rhea> c) how to we version it? 20:10:49 <Rhea> d) what of all of the above can we combine in what ways? 20:11:12 <Rhea> Anything i'm forgetting? 20:11:44 <tmds> the dependencies between the packages 20:11:57 <Rhea> yep 20:12:21 <Rhea> can we move on with the meeting to end it, after which i guess i'll see about creating said ticket? 20:13:28 <Rhea> btw dotnet/core-setup issue? 20:13:30 <omajid> Rhea: list looks good to me. 20:14:24 <omajid> Rhea: what issue is this? 20:14:38 <Rhea> #action Rhea issue to dotnet/core-setup - Linux Packaging - what are we packaging, how do we call it, how do we version it, what are dependences between, and how can user combine versions/whatever at the same time 20:14:40 <Rhea> this 20:14:48 <omajid> oh. 20:15:09 <omajid> sdk is cli component. but sure, core-setup to starts with should be fine 20:16:32 <Rhea> #info === [COMPLETE] Rhea rewrite the Idea #1 to reflect recent findings === 20:16:43 <Rhea> I did not put it up yet but more-less it's fine i guess... 20:16:58 <Rhea> #link http://etherpad.rhea-ayase.eu/p/dotnet-gsoc2017 20:19:17 <Rhea> #info === [INCOMPLETE] nmilosev create a ticket tracking source build for f26 (25) === 20:19:29 <Rhea> #action nmilosev create a ticket tracking source build for f26 (25) 20:19:43 <nmilosev> sorry, will do this, as soon as I try again with the source-build 20:19:55 <Rhea> yup no worries, no rush 20:20:12 <Rhea> Do you guys have anything else to chat about? We've been at it for a while 20:20:18 <Rhea> got stuck on ... naming and sh...stuff 20:20:26 <omajid> sorry. 20:20:30 <Rhea> :D 20:20:35 <Rhea> #topic Packaging progress 20:20:45 <Rhea> #topic Open Floor 20:20:49 * Rhea shrugs 20:20:56 <Rhea> calling the meeting over once 20:20:59 <Rhea> twice 20:21:01 <Rhea> ... 20:21:09 <Rhea> #endmeeting