21:00:01 <notmyname> #startmeeting swift
21:00:04 <notmyname> hello, world
21:00:06 <openstack> Meeting started Wed Mar 22 21:00:01 2017 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:09 <openstack> The meeting name has been set to 'swift'
21:00:12 <jungleboyj> Hello.
21:00:12 <notmyname> who's here for the swift team meeting?
21:00:15 <jrichli> hello
21:00:15 <timburke> o/
21:00:17 <mattoliverau> o/
21:00:21 <alecuyer> hello!
21:00:26 <m_kazuhiro> o/
21:00:29 <cschwede> o/
21:00:33 <rledisez> hello o/
21:00:34 <acoles> hi
21:00:36 <kota_> hello
21:00:55 <tdasilva> o/
21:01:41 <notmyname> welcome
21:01:45 <notmyname> agenda is at...
21:01:48 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:01:58 <notmyname> lots of bullet points, so let's see how fast we can go
21:02:06 <notmyname> #topic follow-up from last week
21:02:18 <notmyname> a few things we talked about last week had some follow-up for this week
21:02:39 <notmyname> https://review.openstack.org/#/c/444604/ has landed, closing https://bugs.launchpad.net/swift/+bug/1657246
21:02:39 <openstack> Launchpad bug 1657246 in OpenStack Object Storage (swift) "Proxy logs wrong request method when validating SLO segments" [Critical,Fix released] - Assigned to Janie Richling (jrichli)
21:02:54 <notmyname> thanks timburke jrichli mahatic and zaitcev for that
21:03:10 <notmyname> I'll get a backport for that proposed soon
21:03:42 <notmyname> also, rledisez (and alecuyer) said they'd get an etherpad started so we can discuss object server compat testing
21:03:46 <notmyname> and that's done too
21:03:51 <notmyname> #link https://etherpad.openstack.org/p/swift-object-server-tests
21:04:38 <notmyname> we asked for review on https://review.openstack.org/#/c/445160/ since it introduces a new api semantic (and it's a lot easier to get it right the first time)
21:05:10 <notmyname> we got some reviews (from clayg and rledisez), but please keep an eye on it as thurloat works on it
21:05:29 <notmyname> and lastly...
21:05:43 <notmyname> https://etherpad.openstack.org/p/composite_rings is for discussion about the best way to expose composite rings
21:05:56 <notmyname> there's some discussion going on there, and it would be good for everyone to read over it
21:06:02 <notmyname> (and leave comments!)
21:06:17 <notmyname> that's all the follow-up stuff I had. did I forget anything?
21:07:03 <notmyname> ok, I'll take that as a "no"
21:07:08 <notmyname> #topic FYI things
21:07:19 <notmyname> a few things to be aware of (and participate in)
21:07:46 <notmyname> timburke: you've noticed some nightly gate failures recently. can you share any more about that? any links?
21:07:54 <notmyname> or ideas on finding the issues?
21:08:04 <mattoliverau> timburke: yeah, are there more stable failures?
21:08:29 <timburke> no clue on the reasons. but there's been like 5 this month?
21:08:29 <clayg> are just like flakey unittests that we already patched on master?
21:08:30 <cschwede> stable failures?
21:08:38 <kota_> around tox py27 xfs?
21:09:06 <timburke> http://logs.openstack.org/periodic-stable/periodic-swift-python27-newton/fc260fd/
21:09:14 <timburke> http://logs.openstack.org/periodic-stable/periodic-swift-python27-newton/51cf2e4/
21:09:20 <timburke> http://logs.openstack.org/periodic-stable/periodic-swift-python27-newton/aa54677/
21:09:27 <timburke> http://logs.openstack.org/periodic-stable/periodic-swift-python27-mitaka/50c0108/
21:09:35 <timburke> http://logs.openstack.org/periodic-stable/periodic-swift-python27-newton/687f8d9/
21:09:50 <notmyname> timburke: how did you see/find these? is there a graph or list or soemthing somewherE?
21:09:58 <timburke> for reference, we would previously see one failure roughly every two months
21:10:51 <timburke> notmyname: go subscribe to http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint then set up filters so everything not-swift is automatically marked as read?
21:10:54 <kota_> ah, it's in stable branch with periodic check
21:11:03 <notmyname> timburke: ah
21:11:10 <mattoliverau> maybe it is an intermittant falure. I can start running py27 unit tests on newton in a loop, but assume your already doing that thing
21:11:54 <notmyname> mattoliverau: actually, I think that would be really helpful
21:12:12 <notmyname> I'm not sure that timburke has done much more than read the test output
21:12:15 <mattoliverau> kk, I'll start setting it up now :)
21:12:19 <notmyname> mattoliverau: thanks :-)
21:12:36 <notmyname> timburke: thanks for noticing and bringing it up
21:12:43 <mattoliverau> +100
21:12:55 <notmyname> other FYI things...
21:13:04 <timburke> as much as anything, i just figure it'd be good if people took a look at the failures and report back if they see anything familiar. "oh yeah, i remember tracking down that intermittent failure in patch X. maybe we should backport that"
21:13:29 <notmyname> the TC has a newly proposed tag for "never-breaks-compat". https://review.openstack.org/#/c/446561/
21:13:40 <notmyname> clayg: thanks for commenting on it (and I agree with what you said)
21:14:14 <notmyname> but the patch proposer assumed it would be something that would apply to swift, but that's a choice that we need to make
21:14:36 <notmyname> so read over it and be aware of it. think about if that's something you think we should apply to swift or not
21:14:55 <notmyname> also, the boston summit is coming up soon
21:15:04 <notmyname> I've learned more how the process for sessions will work
21:15:24 <notmyname> this week (THIS WEEK) please add anything you want to talk about at the summit to https://etherpad.openstack.org/p/BOS-Swift-brainstorming
21:15:44 <timburke> on the never-breaks-compat: i think they really ought to break that down between client API and operator config. as it is, i'd still rather like to drop post-as-copy
21:16:11 <notmyname> early next week I'll take what's there and use the provided session submission tool to propose sessions
21:16:27 <clayg> timburke: i had assumed it was limited to client api - you should put that in a review comment - makes sense to me
21:16:36 <notmyname> timburke: +1
21:16:52 <notmyname> the summit sessions are supposed to be stuff that can't be discussed elsewhere because in other places there aren't the right people
21:17:12 <notmyname> that means that the boston sessions should be more ops focussed (eg dev design sessions for the PTG)
21:17:45 <notmyname> and finally, note that we're in the middle of time changes around the world.
21:17:47 <notmyname> US has passed, EU is this weekend, AUS is next weekend. Japan doesn't do this sillyness. meeting time is 2100UTC (which doesn't change)
21:18:07 <clayg> notmyname: how many things do you have to select how long should a topic be (i.e. how much ground do we try to cover)
21:18:11 <notmyname> but also note that affects our tx overlap
21:18:31 <notmyname> clayg: 40 minute sessions (with a very tiny possibility of having a double session)
21:18:57 <notmyname> any questions on all those FYI things?
21:20:04 <clayg> there's not much getting added to https://etherpad.openstack.org/p/BOS-Swift-brainstorming
21:20:14 <notmyname> yeah
21:20:23 <notmyname> I'm not sure how I feel about that, honestly
21:20:24 <clayg> notmyname: I think there must be some trepidation about what's appropriate
21:20:51 <notmyname> because on the one hand, the previous summit sessions that aren't dev design sessions are largely "ops feedback"
21:20:54 <clayg> but i'm looking at the list of people attending ... i know what I want to talk about those people - let's just plan to talk about that!
21:20:58 <notmyname> so this etherpad isn't actually too bad
21:21:21 <notmyname> but I think you're right too -- trepidation and uncertainty about what is appropriate to propose
21:22:02 <notmyname> if we don't propose anything, we won't have much relevant swift stuff at the summit. if we propose a lot of stuff, we might not get it accepted, but we'll likely have some
21:22:22 <kota_> notmyname: one question
21:22:26 <notmyname> so if you're not sure if something is appropriate, then write it down. worst that can happen is that it doesn't get selected
21:22:29 <notmyname> kota_: yes?
21:22:39 <acoles> timburke: so I wonder , would the backwards compat thing mean we couldn't start to version DLO, just in case someone out there relied on the current behaviour?
21:22:56 <kota_> notmyname: I'm still not getting all for the forum which say like "that should be long-term future discussion"
21:23:05 <clayg> acoles: I think eventually the tags just signal intent + whatever you can manage to test for
21:23:28 <clayg> acoles: If tempest magically tested that behavior and we needed/wanted to change it I think we just make a case like we would have to do anyway
21:23:55 <timburke> acoles: i'm torn. i could see an argument for it falling into the security-fix category
21:24:04 <kota_> notmyname: I always want to land all my patch asap so it may be in Pike so some ideas still be in the list may be in Pike or soon, so it's a reason I did not write so much there
21:24:08 <timburke> (but then i'm biased toward wanting it to land :-)
21:24:10 <notmyname> kota_: I think the reason for saying that is because they imagine that the forum would be requirements gathering for the Q or R cycles instead of stuff that will be worked on right now
21:24:17 <notmyname> kota_: :-)
21:24:22 <clayg> tdasilva: cschwede: can you guys come to BOS to talk about ring management?
21:24:41 <notmyname> kota_: yeah, I'm with you. land all the patches right now :-)
21:24:54 <cschwede> clayg: not sure yet
21:24:56 <acoles> timburke: right! well let's land it quickly :)
21:24:57 <kota_> yeah, and if we could use the forum like as the ptg or past hackathon, it seems to be easy to write something for everyone
21:24:59 <clayg> tdasilva: cschwede: I feel like a forum ops summit might be a good place to do that!?
21:25:14 <tdasilva> clayg: funny enough, it will probably be easier for cschwede to be there than me....trying to figure out funding atm...
21:25:31 <notmyname> kota_: I don't think the highly separated (1) requirements (2) planning (3) develop (4) deploy schedule that's implied from some openstack projects applies very well to how we've been successful in swift
21:26:05 <clayg> tdasilva: cschwede: esp. if we can get word out to people that might be doing openstack deployment kind of stuff - or etcd config management stuff - get some fresh ideas on what ring management might look like from someone that doesn't "know better"
21:26:20 <tdasilva> clayg: but, yeah, i will try to make it at least one day
21:26:30 <notmyname> oh man, gotta get me some etcd configs
21:26:34 <tdasilva> clayg: yeah, i was interested in that whole etcd config mgmt stuff
21:26:36 <kota_> notmyname: k, thanks
21:26:39 <acoles> notmyname: I had thought the current etherpad was for ops-feedback-type-sessions, not swift-devs-ptg-type session proposals? was I wrong?
21:26:40 <cschwede> clayg: but it's a good idea to discuss this with ops, i'll put this on the etherpad
21:27:01 <acoles> tdasilva: or we'll come to you!
21:27:30 <cschwede> acoles: y'all should come over here ;)
21:27:36 <tdasilva> acoles: works for me! :)
21:27:42 <notmyname> acoles: my impression is the same as you. more like ops/deployment stuff. but that's historically been intertwined with dev sessions within the swift community (IMO). so it's hard to draw a distinct line
21:27:44 <clayg> acoles: nobody knows - i think if we have to cut we prefer sessions that can take feedback/requirements - but that's design/planning too
21:28:31 <notmyname> IMo if there's something our community needs to talk about in order to make swift better, then write it down.
21:28:40 <mattoliverau> who is selecting, this the openstack powers to be? or us?
21:28:45 <clayg> notmyname: +1
21:28:46 <acoles> notmyname: clayg: I just hadn't added topics in the usual fashion that would be dev focussed
21:28:46 <mattoliverau> ie topics.
21:29:00 <notmyname> yeah, the Powers That Be. (I think that's the TC and User Committee)
21:29:11 <mattoliverau> I worried to put something up that I need to be there, but then can't get approval or funding to turn up
21:29:26 <clayg> notmyname: OHHHHH, they'll pick 'em from the etherpad - or notmyname has to submit something?
21:29:43 <notmyname> mattoliverau: if we've got something in swift that can only happen with one person, then that's another problem, TBH. (ie write it down anyway)
21:29:55 <notmyname> clayg: no, they will pick from submitted sessions
21:30:16 <clayg> sorry I think i zoned out
21:30:18 <notmyname> we as a team need to write down the stuff we want to talk about, then someone submits those via the sessions submission tool
21:30:21 <clayg> notmyname: do you submit sessions?
21:30:26 <notmyname> yeah
21:30:47 <notmyname> it doesn't have to be me, but yeah, I was planning on doing it
21:30:58 <clayg> notmyname: could you name a session "EC feedback" and then if no one has feedback we just talk about the reconstructor rledisez's patches?
21:31:24 <notmyname> sure
21:31:26 <notmyname> :-)
21:31:37 <kota_> clayg: :-) sounds nice
21:31:44 <clayg> I like the "let's write down what we need to talk about in Boston" - then we'll see what happens with the TC process
21:31:51 <notmyname> exactly
21:31:52 <clayg> or foundation/user-group whatever
21:31:54 <clayg> they're *trying*
21:32:00 <clayg> if it sucks - well tell them and why
21:32:24 <notmyname> and if, worst case, we can only end up talking about things in the hallway (or tdasilva's house), then at least we've got a list of stuff we can use to start the conversation
21:32:41 <clayg> k i'm set
21:32:45 <notmyname> ok :-)
21:32:49 <mattoliverau> kk sounds like a plan
21:32:57 <notmyname> any more questions? I want to move on to the next topic
21:33:09 * tdasilva 's house offers food with conversation
21:33:48 <notmyname> #topic generic diskfile implementation (ie OVH LOSF)
21:34:00 <notmyname> #info LOSF = Lots Of Small Files
21:34:16 <clayg> i liked where the entrypoints patch was going near as I can tell
21:34:21 <clayg> awesome work there
21:34:25 <notmyname> alecuyer is working on optimizing swift for lots of small files
21:34:30 <notmyname> and added them item to the agenda
21:34:35 <notmyname> he's got an etherpad up...
21:34:41 <notmyname> #link https://etherpad.openstack.org/p/swift-losf-base
21:34:56 <notmyname> and would like to give a very brief overview of the direction
21:35:02 <alecuyer> right. We are trying, with rledisez, to make it easier to add alternative diskfile implementations
21:35:23 <alecuyer> so there is the patch clayg just mentionned
21:35:38 <notmyname> #link https://review.openstack.org/#/c/436406/
21:35:52 <notmyname> that one?
21:36:08 <rledisez> #link https://review.openstack.org/#/c/447129/
21:36:10 <rledisez> that one
21:36:14 <notmyname> thanks
21:37:09 <alecuyer> and another point. When working on the prototype for LOSF, I had to deal with callers outside of diskfile that use full path as arguments (path to objects, partition, etc)
21:37:11 <notmyname> alecuyer: so what's the current state, and where do you need feedback? how can the rest of us help?
21:37:22 <alecuyer> that may not make sense for non-file based backends
21:37:48 <alecuyer> So I had to emulate listdir, and parse paths to extract information
21:38:19 <alecuyer> It would be easier if the functions passed "location" arguments, such as policy, partition, ohash
21:38:42 <alecuyer> I have started to patch some functions in DiskFileManager and in callers to do that.
21:38:56 <alecuyer> The LOSF "manager" functions would have the same prototypes
21:39:19 <alecuyer> So I was wondering what if you think that would be a correct approach
21:40:27 <notmyname> alecuyer: from a high-level (ie you talking about it and me not having looked at the code), i like it. it sounds like the right approach
21:41:10 <clayg> alecuyer: I would slighly prefer the interface optionally support 'suffix' as a param than have all the callers have to ohash[-3:]
21:41:39 <notmyname> the https://etherpad.openstack.org/p/swift-losf-base etherpad would be a great please to leave feedback (but since etherpads are hard for collaboration, please leave your nick next to what you type)
21:41:41 <clayg> alecuyer: similarlly it might make sense to just cache some state on the instance and take less params - let implementations use what they need
21:41:48 <alecuyer> clayg, ok. We have seen suffix will be an issue because it is "hardwired" at least in the replicator , I think
21:42:15 <alecuyer> notmyname, if the approach sounds right I will post patches and link to them in the etherpad
21:42:24 <notmyname> cschwede: acoles: based on your part power increase and ec work, I'd love to see your feedback
21:42:29 <clayg> alecuyer: it's not a terrible place to split up the partition - were you going to rework get_hahes to an entirely different format?
21:42:37 <tdasilva> alecuyer: i'm not sure, but i'm wondering if we should look at a tier above for abstraction, since it is called *diskfile*. My fear is that we might try to change it to fit something it wasn't made for
21:43:06 <cschwede> notmyname: and tdasilva as well, he's a diskfile expert!
21:43:16 <notmyname> tdasilva: who would come along and implement a "Diskfile" for something that's not a local disk?!?!?
21:43:30 <notmyname> ;-)
21:43:31 <tdasilva> rofl
21:43:35 <tdasilva> touché
21:43:41 <clayg> alecuyer: for context tdasilva maintains the swift-on-file diskfile; i mainained a out-of-tree diskfile implementation in another life - but I think it *mostly* had to reimplement stuff needed for replication
21:43:44 <tdasilva> but...it is still files!
21:44:03 <alecuyer> clayg, we have not done so at the moment. We're not going for a full rewrite, initially at least !
21:44:21 <alecuyer> thanks for the context :)
21:44:40 <clayg> alecuyer: that sounds good to me - so anyway - I think "suffix" as a concept may contine to exist - even if it's not strictly needed by your implementation
21:44:47 <rledisez> clayg: current idea is « just » to plug a new disk file without disrupting everything around (not patching replication that’s your job clayg ;))
21:45:13 <clayg> I'm suggesting you continue to send it down - but ignore it - rather than try to get rid of it ... maybe.... maybe not
21:45:24 <clayg> rledisez: understood
21:45:32 <alecuyer> in the prototype, the patches to replication were minimal to get it working (for replication), I believe < 50 lines
21:45:42 <notmyname> yeah, that's good to keep in mind. the problem being solved here is to optimize a real problem, not to make the ultimate abstraction layer for anything :-)
21:45:52 <acoles> alecuyer: my first reaction is that if there are improvements to the interface that will help then we should consider them (like not passing full paths). if possible, small tactical patches would be good
21:46:22 <alecuyer> acoles, that is what we had in mind, yes, small patches to build on
21:46:28 <clayg> alecuyer: the etherpad makes reference specifically to _get_hashes - and I think the interfaces used outside of the object server are the most coupled with the existing implementation
21:46:52 <clayg> not to the interfaces used by the object server ... it sounds very fine/correct
21:47:47 <clayg> i think i lost part of the sentence
21:47:55 <rledisez> clayg: _get_hashes is an example. an actually, we need very few functions patched as the coupling between callers and diskfilemanager is about 10 functions
21:48:07 <clayg> alecuyer: i was just trying to say that the less changes you have to make to the interface in the object server - the stronger you should feel you're doing it right
21:48:12 <rledisez> and most of them are ok for what we need
21:48:26 <alecuyer> clayg, right, thank you for clarifying :)
21:48:40 <clayg> rledisez: ok, yeah and the REPLICATE verb is the outlier - that's part of the "replication" interface IMHO
21:48:58 <clayg> other stuff should be "internal" - but jesus - it's not like we ever tried to documnt what the f'ing interface is
21:49:22 <clayg> there's annoying coupling everywhere - the *type* of the exception raised on certain conditions is part of the "interface" for christ sakes
21:49:46 <rledisez> ^ good point, we should note that alecuyer
21:49:51 <clayg> ok, but it sounds great - can't wait to see a patch!
21:50:00 <alecuyer> I think there is a comment about it -the exception
21:50:01 <notmyname> +1
21:50:36 <notmyname> if we could keep discussing it in the etherpad and in IRC, that would be great
21:50:44 <alecuyer> ok ! thank you all for the feedback and please do send more in the etherpad
21:50:46 <notmyname> alecuyer: thank you for working on this. i'm really excited about it
21:50:50 <clayg> rledisez: alecuyer: try not to get *too* caught up on a crusade to define the perfect diskfile interface - KISS
21:51:05 <notmyname> #topic open discussion
21:51:05 <alecuyer> yes
21:51:08 <acoles> alecuyer: don't assume that because code exists on master that it is universally considered to be perfect :) there has been a lot of history in diskfile, so please challenge anything you find that seems wrong
21:51:12 <notmyname> ok, a couple of things here
21:51:18 <notmyname> acoles: +100
21:51:22 <rledisez> about patches, our goal is to land that as fast as we can to build the new diskfile on clean bases. so these modifications and the pkg_resources will be submitted very soon
21:51:52 <notmyname> first, i had an idea that I was curious about. "call your patches"
21:52:16 <notmyname> if you're about to review or look at a patch in gerrit, say somehting in IRC. like, "I'm looking at patch 345345"
21:52:33 <notmyname> then, within an hour or two, leave a comment in gerrit on the patch
21:52:45 <notmyname> call your patch, leave a comment
21:52:52 <notmyname> I think this will do a couple of things
21:53:02 <clayg> rledisez: we'll try to keep up!  Obviously any help you guy apply to the review backlog makes a huge difference to our throughput - if you think something is not important and you see reviews going on there you need to find some way to communicate that
21:53:03 <notmyname> first, it will help us all know who's looking at what
21:53:21 <clayg> triage takes a village - everyone can get caught up chasing dragons and lose sight of the prize
21:53:49 <notmyname> and second, I hope it will help reduce the perceived "cost" of leaving a comment
21:54:04 <clayg> notmyname: but what if I don't want to admit how long it takes me to review things sometimes :'(
21:54:09 <notmyname> ie leaving a comment is just a thing you do and small comments are ok
21:54:26 <clayg> what if I say in channel I'm going to review something and then don't because I'm a dirty lazy liar!
21:54:34 <notmyname> clayg: it's ok. I've learned that in a group, if you feel a certain way, probably three other people do too :-)
21:55:34 <clayg> notmyname: I don't think I follow how this reduces the cost of leaving a comment?
21:55:55 * jungleboyj is curious about that as well.
21:56:08 <clayg> notmyname: I've historically been a big advocate of "try to comment with clear instructions to make the patch meragable" - that can a non-trivial amount of work
21:56:21 <notmyname> because if leaving a comment, even a "I looked at it and didn't find anything yet, +0", if that becomes common, then it's easier for everyone to leave a comment
21:56:28 <clayg> notmyname: I tend to be a hypocrite about it too
21:56:52 <notmyname> because if you don't ever comment until the comment is perfect, it's like not submitting code until it's perfect -- it's impossible and leads to not much getting done
21:56:54 <clayg> notmyname: but it "seems" like a reasonable goal?  And from someone on the other side - clear instructions help *a lot*
21:57:01 <notmyname> definitely
21:57:33 <jungleboyj> Hmmm, I leave a lot of imperfect comments.  :-)
21:57:37 <clayg> notmyname: ok, yeah I kinda like that.... we should update the review guidelines!
21:57:56 <notmyname> we can't all be in the same room all the time, so "hey I'm looking at Foo" is something that can be helpful to coordinate
21:58:09 <notmyname> and it might even lead to a "oh! I was looking there too, and I found ..."
21:58:28 <clayg> timburke: does this sound right to you?  Maybe the difference is the +0 and the -1
21:58:31 <acoles> FWIW I sometimes leave a 'part-complete' review and say its only partial. usually it means I have not yet worked through 100's of lines of test changes, but have some comment on the real code.
21:58:51 <jungleboyj> notmyname: Doesn't seem like a bad idea.  I know I have collided with people on many occasions .
21:58:56 <clayg> -1 "fix this and we're mergable" +0 "you can either pretend I didn't leave this here or read it - my review is WIP"
21:59:07 <notmyname> WIP review :-)
21:59:30 <acoles> we need real and imaginary numbers for votes :)
21:59:38 <notmyname> because even if you don't get to come back to your review, it's a starting point for the next reviewer!
21:59:44 <timburke> clayg: i can get behind it. i certain will leave +0s when i've done a partial review, not found anything blatantly wrong, but definitely had some questions raised
21:59:45 <notmyname> acoles: multi-demensional reviews?
22:00:14 <notmyname> ok, we're at time
22:00:19 <clayg> notmyname: the review history is *super* important to me when I come to patch that's been at it awhile
22:00:20 <acoles> notmyname: +100i
22:00:43 <notmyname> I saw that PavelK had a patch question in -swift about a patch. I wanted to get to it here, but we should look at it in -swift
22:00:43 <clayg> notmyname: sometimes I wish we could a review "summary" or something :P
22:00:52 <notmyname> thank you for your work on swift
22:00:57 <notmyname> #endmeeting