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