15:00:31 <fungi> #startmeeting tc
15:00:32 <openstack> Meeting started Thu Jun 28 15:00:31 2018 UTC and is due to finish in 60 minutes.  The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:35 <openstack> The meeting name has been set to 'tc'
15:00:38 <fungi> #topic Office Hour
15:00:41 <mnaser> bonjour o/
15:01:01 <fungi> #chair mnaser dhellmann ttx smcginnis cdent TheJulia zaneb
15:01:01 <dhellmann> o/
15:01:01 <openstack> Current chairs: TheJulia cdent dhellmann fungi mnaser smcginnis ttx zaneb
15:01:05 <pabelanger> o/
15:01:06 <TheJulia> o/
15:01:12 <fungi> #chair pabelanger
15:01:13 <openstack> Current chairs: TheJulia cdent dhellmann fungi mnaser pabelanger smcginnis ttx zaneb
15:01:16 <mugsie> o/
15:01:20 <fungi> #chair mugsie
15:01:20 <openstack> Current chairs: TheJulia cdent dhellmann fungi mnaser mugsie pabelanger smcginnis ttx zaneb
15:01:26 <ttx> o/
15:01:38 <dhellmann> for those just joining, we were discussing the pre-PTG meeting plans
15:01:56 <jroll> late on the food topic, but before things get busy, just wanna point out denver seems to have thousands of microbreweries :)
15:01:58 <dhellmann> I am waiting to hear if we have a conference room, but have been reassured that we could likely use the lounge if we have to.
15:02:04 <ttx> dhellmann: where do we stand on an "additional workshop around an established conference" ?
15:02:15 <ttx> Was that abandoned ?
15:02:20 <dhellmann> the general trend seemed to be for an afternoon-only meeting, so plan your travel accordingly
15:02:24 <dhellmann> ttx: good question
15:02:40 <ttx> CFP for Open Source Summit in Edimburgh closes Sunday iirc
15:02:41 <dhellmann> I had thought maybe this pre-PTG thing would make that unnecessary, but that wasn't really clear.
15:03:00 <ttx> Maybe we can postpone
15:03:03 <smcginnis> My impression was that while a lot of us would like to have a workshop, there didn't sound like there was a good time or place for everyone to meet.
15:03:18 <ttx> ok
15:03:30 <dhellmann> Alan Clark did ask to join us on Sunday in Denver, and I thought it might be a good opportunity. Does anyone have any objections to including him?
15:03:39 <smcginnis> Not saying I don't think we should try for it, but there were some challenges to work through yet if we do.
15:03:41 <ttx> In September we'll have a better idea of teh early-2019 conference landscape and could pick one
15:03:43 <fungi> i'd welcome his presence
15:03:49 <smcginnis> dhellmann: That would be great!
15:03:53 <mnaser> likewise
15:03:53 <fungi> or anyone from the community really
15:03:54 <cdent> alan showing up would be great
15:03:55 <mugsie> yeah, that seems like a good idea
15:04:04 <dhellmann> smcginnis : yeah, I think we might have a better chance scheduling something off-peak conference season
15:04:15 <dhellmann> ok, I will relay the current vague plans
15:04:17 <dtroyer> fwiw, I plan to be there… (Sunday PTG)
15:04:23 <smcginnis> Q1 2019 might give us enough time and be a good time of year to try to do something.
15:04:36 <cdent> we could consider doing some virtual video conferencing if people were up for it, but that night be a pain
15:04:43 <smcginnis> Leaving MN in February to go to Cancun or Hawaii works for me.
15:04:48 <dhellmann> which are, we'll meet some time after lunch, so as not to try to make anyone take really early flights to get there first thing
15:04:49 <ttx> ok, noted. i might still go to Edinburgh :P
15:05:08 <scas> there may be an opportunity for me to be attend the ptg on behalf of chef openstack. i suspect it'll be more for me to whip my deceased equine than talk about chef itself
15:05:10 * jroll <3 edinburgh
15:05:12 <cdent> ttx I'm still thinking about it as well, but I'm struggling with seeing the future well
15:05:14 <scas> s/words/words/
15:05:19 <dhellmann> ttx : I will be there for EuroPython so opted not to make 2 trips to the same place so close together.
15:05:40 <ttx> I'll apply for CFP -- usually mentioning OpenStack in the abstract is a good way to get rejected
15:05:53 <dhellmann> le sigh
15:05:58 <smcginnis> Hah, that does seem to be the case these days.
15:06:15 <fungi> yeah, i avoid mentioning openstack in any cfp submission due to openstack fatigue
15:06:49 <ttx> I also wanted to discuss diversity tracking, if nobody else has anything more urgent
15:07:13 <fungi> i liked the "bus factor" recharacterization
15:07:18 <ttx> It feels like we have several options on the table
15:07:18 <dhellmann> I was going to ask where things stood with the work on "job descriptions" but I didn't see dims sign in
15:07:26 <fungi> helps focus on the actual concern rather than the abstract measurement
15:07:37 <ttx> 1- try to adjust the metrics and continue to do tags
15:07:58 <ttx> 2- try to adjust the metrics but use them to feed questions to teh health Tracker for deeper dive into data
15:08:05 <ttx> 3- drop tracking altogether
15:08:19 <openstackgerrit> Jeremy Stanley proposed openstack/project-team-guide master: There are no core developers, only core reviewers  https://review.openstack.org/578819
15:08:22 <ttx> 4- Produce a comprehensive report every cycle
15:08:36 <ttx> I' not convinced 4 is worth the effort
15:08:54 <ttx> I'm convinced (1) is more destructive than useful
15:08:54 <smcginnis> Agree re: 4
15:09:12 <ttx> so I'm somewhere between 2 and 3 at this point
15:09:17 <fungi> 2 seems like a reasonable compromise
15:09:17 <cdent> I think we should stop publishing the data, but produce it regularly to use it to inform human interactions
15:09:24 <ttx> cdent: ++
15:09:25 <smcginnis> I was just going to say the same - somewhere between 2 and 3.
15:09:28 <ttx> that's where I am
15:09:47 <ttx> Have teh data, but don't make it more significant than it actually is
15:10:07 <ttx> because the more i look into it, the more brittle I see it is
15:10:08 <scas> measuring the thing but not having it published is where i'd go, too. better to measure and not need
15:10:22 <TheJulia> 2 seems reasonable and the lesser lift work wise to implement.
15:11:11 <scas> it does give a rough idea as to where things stand, but it's not something i'd want to plaster on the wall
15:11:30 <ttx> And as I mentioned in a recent remark on this channel, 67% corporate bus factor on swift due to commit % is less critical than 67% for Masakari.
15:11:44 <ttx> As one is more featurecomplete than the other
15:12:03 <fungi> yeah, and i agree fully that badgifying it via governance tags just turns it into something teams will complain is unfairly casting them in a poor light
15:12:24 <ttx> If Swiftstack abandoned Swift I feel like Swift would survive ok. If NTT abandoned Maskari, it would be a walking dead
15:12:38 <scas> it brought me out of my foxhole since chef is pretty relevant there
15:12:44 <ttx> due to lack of an ecosystem of users
15:13:20 <ttx> The only drawback of 2/3 is that you don't communicate that information on project health to consumers anymore
15:13:52 <dhellmann> do we know if consumers were actually using that information?
15:13:54 <ttx> except if they find the not-so-secret wiki url
15:13:56 <cdent> we should care most about openstack health, not individual projects?
15:13:58 <mugsie> dhellmann: ++
15:14:01 <fungi> if ntt abandoned masakari it would be a zombie at least until some other interested party picked it back up (a la blazar)
15:14:21 <dhellmann> of course, they can't use it if we don't publish it
15:14:22 <ttx> Trove is actually my favorite example :)
15:15:34 <ttx> dhellmann: yeah, I'm not sure how much corporate diversity actually plays a role in deployment decisions
15:16:03 <cdent> sorry, I gotta run, will catch up
15:16:24 <ttx> But I feel like it's a more positive message to post "you can use Barbican now, the TC says it's solid" rather than "don't use TripleO, only Red Hat contributes to it"
15:16:34 <mugsie> ttx: I would suggest it doent at all
15:16:47 <scas> 'does it blend without cutting me to shreds' is the general sentiment that i've seen from various interactions with my downstreams in the deploy space
15:17:08 <ttx> scas: but it's a more complex statement than a diversity tag, right
15:17:10 <mugsie> ttx: but we don't make judgements on the code - we can't say Barbican is solid, just that more than one company works on it
15:17:14 <scas> ttx: very much so
15:17:24 <ttx> mugsie: well maybe that needs to change
15:17:32 <scas> ttx: for core openstack, swift the big exception, you could say that chef is fairly stable
15:17:41 <mugsie> quite possibly
15:18:23 * mugsie is just imagining the wall of flames from the first TC code review
15:18:56 <ttx> mugsie: right... I'm just suggesting we somehow communicate that it's time for people to rely more on Designate for example
15:19:07 <fungi> fireproof pants mode *on*
15:19:09 <scas> so long as 'someone' is keeping up with build failures and extra-community developments, diversity is a third or fourth degree factor. the user survey metrics for chef are fairly stable because the main use case is 'fairly stable', to overuse the phrase. but that's a complex thing to measure
15:19:14 <mugsie> well, bolding us in the project map would help :P
15:19:18 <ttx> not saying that the others are less ready :)
15:19:33 <ttx> Bold is the new core
15:20:23 <ttx> anyway, that's a bit of a tangent
15:21:02 <ttx> OK! so: I will refine my busfactor scripts and post them to governance repo
15:21:22 <dhellmann> ++
15:21:28 <ttx> I will highlight the most disturbign stats in the HealthCheck page so taht those can be raised in future health checks
15:21:47 <dhellmann> that sounds good, too
15:21:59 <ttx> and I will propose a removal of the existing diversity tags
15:22:35 <ttx> mnaser: if you want to take some of those work items, feel free :)
15:22:55 <fungi> it would be nice, in a bikesheddy sort of way i suppose, to come up with a less morbid term than "bus factor" to describe this concept
15:22:56 <ttx> but I'm probably in a better position to push those
15:23:08 <TheJulia> So what if a team actually doesn't care about the diversity tag?
15:23:10 <ttx> hah
15:23:34 <dhellmann> TheJulia : if it's going away, that doesn't really matter, right? do you mean affiliation diversity in general?
15:23:44 <ttx> fungi: "diversity brittleness" ?
15:23:53 <mugsie> TheJulia: most of us don't really care, apart from the kiss of death from the single-vendor one
15:23:54 <TheJulia> well, I think my mind is going towards tags in general
15:23:57 <ttx> The problem is that diversity has more dimensions
15:24:11 <dhellmann> ttx: "diversity" has so many meanings, I think we always need to include "affiliation" when we talk about it in this way
15:24:14 <dhellmann> to be clear
15:24:15 <dhellmann> yeah
15:24:25 <ttx> fungi: I'll take any suggestion that works both for corporate busfactor and individual busfactor
15:24:27 <TheJulia> mugsie: that was kind of what I was expecting the answer to be, and that is my perception as well.
15:24:41 <fungi> though also affiliation may be irrelevant in the single-contributor case
15:24:54 <ttx> although I'll regret my busfactor.py
15:25:10 <scas> perhaps 'key person risk', to dredge from the old school
15:25:20 <fungi> to be clear, i don't object to it but some people may find the imagery of contributors getting hit by a bus unsettling
15:25:24 <TheJulia> ttx: it can always be renamed ;)
15:25:38 * ttx cries in a corner
15:25:51 <TheJulia> :(
15:25:56 <zaneb> anybody want to talk Adjutant?
15:26:15 * dhellmann would like to hear some other opinions on adjutant
15:26:17 <ttx> fungi: less unsettling than being forked, right
15:26:24 * ttx shuts up
15:26:25 <fungi> heh
15:26:43 <ttx> Adjutant++
15:27:08 <ttx> I was leaning towards +1ing it but didn't want to influence anyone
15:27:28 <dhellmann> I'm still a bit on the fence and am looking for someone to tip me one direction or the other.
15:27:41 <jroll> ttx: fungi: I like "lottery factor", winning the lottery is a much happier scenario where people might just stop working on things :)
15:27:52 <fungi> jroll: or retirement ;)
15:28:02 <jroll> retirement usually isn't so sudden :P
15:28:05 <cmurphy> oops i'm late
15:28:11 <zaneb> dhellmann: I'm pretty relaxed about voting for it, so I'd like to hear more about your concern that its flexible architecture could prove to be a Bad Thing if it results in people writing lots of non-interoperable plugins
15:28:32 <ttx> For Adjutant, I'm fine adding it, because it's easy to remove it afterwards if it ends up being destructive after all
15:28:33 <TheJulia> yeah, retirement seems to be more of a trickledown from what I've seen so far
15:28:46 <TheJulia> "tableflip factor"?
15:28:46 <fungi> jroll: fair. also working on free software already feels like retirement to me at least ;)
15:28:46 <ttx> I think we expressed our concerns
15:28:58 <smcginnis> rage quit factor
15:29:07 <dhellmann> ttx: Is it "easy" to remove? When was the last time we removed a project?
15:29:35 <smcginnis> I wouldn't consider it "easy", but maybe in relation to the work getting it added it would be. :)
15:29:40 <ttx> That would be Fuel and the App catalog.. 2017?
15:29:42 <fungi> we removed fuel, app catalog, akanda
15:29:45 <mugsie> cue?
15:29:48 <fungi> yup
15:30:03 <dhellmann> zaneb : We've done so much work on interoperability with other projects, and place so much value and emphasis on it now, that I'm having trouble just letting go of that.
15:30:07 <zaneb> dhellmann: specifically, in what ways could making it an official project make the downstream plugin problem worse?
15:30:08 <ttx> It's easier than most due to where it would end up in the map
15:30:41 <dhellmann> zaneb : it wouldn't be any different, at a technical level. It would be different because we would be saying "yeah, we don't care about the lack of interop with this one project"
15:30:45 <ttx> dhellmann: I would definitely not accept it if it ended up in the "main" bucket
15:30:47 <fungi> the app catalog removal is probably the most similar, since it was "we're retiring this active effort because it is not the direction we want to take openstack"
15:30:50 <dhellmann> and I guess I prefer not to make exceptions
15:30:54 <ttx> I think that needs clear APIs
15:31:33 <dhellmann> at the same time, I've wished we had the user onboarding features for *ages* (the thing we built at Dreamhost wasn't reusable in any way)
15:32:03 <dhellmann> and to be clear, I will support the decision of the group, whichever way it goes
15:32:12 <dhellmann> *this group
15:32:19 <mugsie> yeah. and the info I would take for onboarding into my cloud is completely different to the info collected by vexxhost for example
15:32:54 <dhellmann> I'm talking post-signup onboarding
15:33:10 <dhellmann> stuff like "welcome! next we're going to create some default networks for you"
15:33:36 <dhellmann> some of what we had to do was driven by our choice of networking architecture and backend
15:33:43 <ttx> dhellmann: re: Adjutant if we add them now they won't be in Rocky anyway, forit release would be Stein
15:33:48 <ttx> first*
15:33:58 <smcginnis> I forget where I read it recently, bit there was some wording around the desire for interop with OpenStack not meaning it's something you can easily switch between providers with absolutely no changes, but rather having a base level of expected compatibility.
15:34:31 <smcginnis> I see adjutant as being outside of that base level and something more on the provider level where it's perfectly fine if vendor a works slightly differently than vendor b.
15:34:31 <zaneb> it's not like we don't have non-interoperable ways of doing it now, it seems like Adjutant is at least a step in the right direction
15:34:50 <smcginnis> But at least both vendors can use a tool supported by the community and not some home grown widely divergent thing.
15:35:03 <mnaser> ttx: i can take on some of these tasks if you want to assign any
15:35:12 <mnaser> i'm still trying to grasp most of the diversity stuff but i'll take any action items
15:35:38 <ttx> mnaser: I'll see if I end up needing help, You have plenty on your plate
15:35:55 <zaneb> smcginnis: and tbh I am less concerned with interop when the interface is Horizon (which anybody can relearn pretty quick) vs. a bunch of scripts that have to be rewritten
15:36:02 <mnaser> ttx: thanks, i've had some unexpected surprises of extra work on my way..
15:36:08 <zaneb> not unconcerned, but definitely less concerned
15:36:16 <smcginnis> zaneb: Same here.
15:36:25 <dhellmann> there is an API, right?
15:36:46 <ttx> zaneb: depending on how much prevalent those sorts of APIs already are, one could even consider that Adjutant is helping standardize overall
15:36:47 * mnaser doesn't like the fact some providers build their own control panels and not use horizon instead
15:36:55 <zaneb> dhellmann: AIUI yes, but mostly for the purposes of exposing it through horizon
15:37:10 <dhellmann> ah, ok
15:37:24 <smcginnis> Even if it's scripted for some reason, I don't see a problem with that.
15:37:36 <scas> mnaser: ++
15:37:42 <ttx> I guess that's a good question -- how many of the OpenStack public clouds already use some sort of proprietary API to integrate with their business logic on $stuff
15:37:50 <smcginnis> As a user, if I've scripted something for working with Vexxhost, I would assume I need to redo some things if I then go to some other provider.
15:37:54 <ttx> If all of tehm do, then Adjutant is a win
15:38:09 <ttx> If none of them do, then Adjutant is likely to increase divergence
15:38:10 <smcginnis> I would assume at least 90+% of them do.
15:38:16 <fungi> in previous discussions, adjutant developers were quite clear the api is and is meant to be user-facign and not merely for web integration
15:39:29 <mnaser> smcginnis: i like to think that what you run against our cloud should be the same as any other cloud
15:39:40 <mnaser> the only thing i'd expect to change are things like.. image id.. flavor..
15:39:42 <mnaser> network id..
15:39:53 <mnaser> that's how i think it should be anyways
15:41:05 <mnaser> my view is that: each company can do it's own thing in a way, but at some point, you will end up with a set of openstack credentials and the experience from that point onwards should always be consistent
15:41:05 <fungi> i expect it was more like for self-service sign-up the information you collect from new customers is likely to be at least somewhat different from the information some other provider might collect
15:41:49 <ttx> fungi: in a lot of cases they piggyback on an existing system
15:41:50 <cmurphy> mnaser: technically some of what adjutant handles is the part before you get the openstack credentials
15:42:27 <fungi> ttx: agreed. especially if cloud services are not the only product/service so they already have a crm and billing system
15:42:38 <mnaser> this might be a bit ignorant of me to ask, but do you *have* to be interop-able to be an official project?
15:43:11 <mugsie> nope
15:43:23 <cmurphy> the deployment tools are an example of projects with no interoperability guarantees because that wouldn't make sense
15:43:24 <ttx> depends what you mean by operop-able
15:43:26 <mugsie> it is a goal of our though
15:43:34 <fungi> https://governance.openstack.org/tc/reference/new-projects-requirements.html
15:43:52 <mnaser> so the way i imagine adjutant is just a collaboration across different providers who would like to stop duplicating their logic and work together to implement their common business logic
15:43:54 <fungi> has some things to say about "basic interoperability with the rest of OpenStack: User-facing API services should support Keystone for discovery and authentication"
15:44:16 <mnaser> and extend it with their own business logic on top, rather than each provider having their own set of onboarding stuff
15:45:03 <mnaser> as long as that is limited to logic that isn't user facing imho
15:45:18 <mnaser> user facing and touching other openstack api services
15:45:36 <mnaser> but anyways, i might be late to this whole convo.  i'll follow the review and comment
15:45:51 <fungi> mnaser: yeah, in adjutant's case rather than wanting to have interchangeable backend drivers with a consistent api, they want the backends to change the api conditionally
15:46:11 <ttx> mnaser: that would be the ideal scenario yes
15:47:01 <mnaser> yeah that's a no bueno imho.  work with other providers and come up with the set of common shared api calls you want to work on: ex.. reset password, etc
15:47:03 <fungi> for me what it boils down to is that we've had examples of dynamic apis in openstack, and our experience to date is that you can't really build redistributable tools around those
15:47:36 <mnaser> i do feel like at that point it's a bit odd
15:47:37 <fungi> so instead you end up with provider-specific clients and sdks
15:47:49 <fungi> which we've also had a proliferation of in the past
15:47:57 <mnaser> like it has it's own queueing and task management tooling
15:48:15 <mnaser> we have tools that do that in openstack which it would be nice to depend on and help the overall ecosystem
15:49:14 <zaneb> one thing we haven't discussed: is there actually interest from other vendors? I only see one email on openstack-dev to that effect
15:49:30 <mugsie> No - we covered that a long time ago, there is no relation between Mistral and Adjutant
15:49:51 <dhellmann> yeah, adjutant "tasks" are not at all like mistral's
15:50:00 <ttx> zaneb: that's a good question yes. If there is no hope of open collaboration aroudn Adjutant, the overall value add is limited
15:50:07 <mugsie> mnaser: every project has it own internal queuing and task managment system
15:50:08 <fungi> (perhaps more like glance's "tasks"?)
15:50:24 <mugsie> yeah, that's pretty close fungi
15:50:37 <mnaser> zaneb: i dont want to speak on their behalf but i think citycloud might be using parts of it
15:50:41 <mugsie> or designate's workers / tasks
15:50:43 <mnaser> tobberydberg: ^ ?
15:51:32 <zaneb> I guess I should check the operators list
15:52:01 <dhellmann> if we can go back to the PTG meeting for a second, Alan asked if it would be appropriate to invite the rest of the board members who may be in town to join us. I don't have a problem with that, except that I don't know how much space we have yet. Is there any other reason not to include them?
15:52:15 <fungi> zaneb: i want to say there was some discussion of it on the operators list last year, but i'll need to find my old notes from the last time i researched it
15:52:34 <zaneb> http://lists.openstack.org/pipermail/openstack-operators/2018-April/015106.html
15:52:42 <ttx> dhellmann: yeah, maybe wait until we know if we have a room... The bar won't be enough if the board comes
15:52:53 <mugsie> dhellmann: I dont think there is an issue, apart from space
15:52:53 <fungi> dhellmann: assuming space is not an issue, i'm cool inviting anyone from the community, even board members
15:52:57 <cdent> dhellmann: only if we want to talk about them behind their backs. I reckon we want to talk about them to their faces
15:52:59 <dhellmann> ttx: yeah, that's what I was thinking. I only asked for space for 13 to start
15:53:24 <dhellmann> I will ping Kendall again today to see where things stand
15:53:31 <fungi> cdent: i certainly prefer to talk about people to their faces ;)
15:54:40 <smcginnis> Maybe we can get the lunch area? It would be great to have the board there if possible.
15:55:02 * mnaser is totally in support of that idea
15:55:22 <smcginnis> Maybe instead of bemoaning not getting invited to board meetings, we just need to invite the board to our meetings.
15:55:27 <mnaser> ++
15:55:35 <dhellmann> there's some other big event going on over that weekend, so space is going to be tight
15:56:00 <mnaser> i think the only thing is as long as it stays a 'tc meeting', but i'm sure we won't have a problem with that
15:56:16 <dhellmann> that was my other question: what do we actually want to talk about?
15:56:17 <smcginnis> Maybe we can all get train tickets and just take over a car and ride around the city all day.
15:56:43 <mnaser> dhellmann: https://wiki.openstack.org/wiki/Technical_Committee_Tracker i think is a good start
15:56:46 <fungi> cue train ascii art
15:56:49 <cdent> dhellmann: isn't september too far away to be agenda building?
15:56:59 <mnaser> we can get a lot of that hashed out imho
15:57:03 <cdent> I reckon it depends on how far we've got on some things
15:57:10 <smcginnis> With the board, I would like more discussion about FOundation direction for expanding to other areas and what projects we're bringing on board.
15:57:23 <mugsie> smcginnis: ++
15:57:31 <cdent> but if we haven't finished it yet, I reckon two things: tech vision and board interaction
15:57:43 <zaneb> smcginnis: AIUI wherever the board has quorum it becomes a Board Meeting and then it's a whole Thing
15:57:55 <smcginnis> True
15:58:23 <dhellmann> this would be "other board members who will be at the PTG" so not necessarily enough people to trigger quorum
15:58:41 <fungi> yeah, i don't anticipate a majority of the board will travel to the ptg
15:58:56 <fungi> most of the elected individual directors likely will
15:59:15 <zaneb> dhellmann: yeah, I think this is fine, just thinking about why 'just invite the board to our meetings' might not be a solution in general
15:59:28 <fungi> and a few of the appointed directors are also active contributors in the trenches as well
15:59:42 <dhellmann> I've suggested we wait to invite anyone else until we have more details about space, and I've pinged Kendall to see what the status on that is. I'll let you all know when I have more info.
16:00:00 <dhellmann> and I need to drop offline for a while, unfortunately, but please do carry on without me
16:00:25 <ttx> I think we are done :)
16:01:01 <fungi> thanks everyone!
16:01:05 <fungi> #endmeeting