20:00:49 #startmeeting tc 20:00:50 Meeting started Tue Jan 17 20:00:49 2017 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:51 * smcginnis is hanging out with jroll in the corner 20:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:54 The meeting name has been set to 'tc' 20:00:57 :P 20:00:57 * AJaeger joins jroll and smcginnis 20:01:09 o/ 20:01:16 Hi everyone! 20:01:22 Our agenda for today is at: 20:01:25 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:33 o/ 20:01:35 I added a few items for the open discussion at the end, so let's keep some time to cover them 20:01:37 o/ 20:01:40 o/ 20:01:42 o/ 20:01:43 o/ 20:01:43 A few easy ones first 20:01:45 #topic Refresh I18n ATC list 20:01:49 #link https://review.openstack.org/417569 20:01:53 Nice refresh, no-brainer for me 20:01:55 ship it 20:02:00 ++ 20:02:08 shipping in 10 seconds 20:02:11 lgtm 20:02:22 do it up 20:02:25 shipped 20:02:31 #topic Amend new-language reference document 20:02:33 #link https://review.openstack.org/418487 20:02:37 Also a pretty simple change 20:02:48 same! 20:02:54 DITTO 20:02:55 ship ship 20:02:55 shipping in 10 seconds unless someone screams really hard 20:02:58 ops 20:03:03 do it! 20:03:03 SHIP 20:03:07 * flaper87 removes caps lock from his keyboard 20:03:08 shipped 20:03:14 OK, let's pick some Pike goals now 20:03:17 #topic Pike goal: support python 3.5 20:03:22 #link https://review.openstack.org/349069 20:03:26 EmilienM: feels like this one has broad support ? 20:03:38 ship... it 20:03:40 ditto again? python 3.5 didn't have any pushback 20:03:44 * flaper87 likes this meeting already 20:03:46 ttx: yes ship it 20:03:48 any reason to hold on this one ? 20:03:48 \o/ 20:03:50 do it up 20:04:00 so many projects are nearly there 20:04:01 it has been sitting around for feedback and has good support 20:04:23 alright, let's do this. Shipping in 10sec 20:04:35 if there are any missing bits of ci standing in the way of projects implementing/testing py3k support, give us a heads up 20:04:41 we currently consider that already done 20:04:48 shipped 20:04:50 fungi : yep. will do 20:04:52 (we being infra) 20:04:54 #topic Pike goal: split out tempest plugins 20:04:55 fungi: y'all have been fantastic 20:04:57 dims too ;) 20:04:59 #link https://review.openstack.org/369749 20:05:09 EmilienM: this one sounds slightly more controversial ? 20:05:10 it seems like this one is still under review 20:05:12 yes 20:05:26 and without mtreinish I'm not sure how far we're going to get 20:05:26 We are running out of time though... should we have a plan B in case this one doesn't make it ? 20:05:39 I have a plan B 20:05:44 https://review.openstack.org/#/c/419706/ 20:06:00 i've abstained so far given the number of ptl -1s on 369749 20:06:02 until today the -1s were for "please add a guide", but now I see a couple people disagreeing with the premise 20:06:21 fungi +1 20:06:26 yes, it's a bit less obviously beneficial than other things 20:06:29 fungi: same here 20:06:46 yeah, it looks like this one needs some extra talking 20:06:50 fungi: honestly, I think that there is confusion about the architecture there 20:07:09 OK, shall we table it until someone (mtreinish?) addresses the concerns ? 20:07:13 sdague: probably so, and i guess the goal can attempt to address that confusion 20:07:14 tempest plugins were never designed to be in branches 20:07:16 TBH, If we manage to do the python3.5 goal for pike, I'll consider it a success already 20:07:19 :D 20:07:23 but let's not let that stop us 20:08:00 EmilienM: shall we table it until someone (mtreinish?) addresses the concerns ? 20:08:03 flaper87 : nova/py35/tempest shows "Pass 1295 Failure 42 Skip 85" :) 20:08:09 ttx: yes, most probably 20:08:10 ttx: yeah, wait til mtreinish is around i suppose 20:08:11 ttx: it seems like we should wait on this one 20:08:13 yeh dims has been making good progress 20:08:23 ok, let's see the backup plan then 20:08:28 #topic deploy-api-in-wsgi 20:08:32 #link https://review.openstack.org/419706 20:08:36 sdague: fwiw in-repo tempest plugins work fine with a small hack in project-config, this is just about ops/users AIUI 20:08:36 ok let me introduce quickly 20:08:39 That one was "moved" to Queens 20:08:50 I was looking for a goal that might have a direct impact on operators 20:08:54 dims: w00h000 20:08:55 and this one is quite interesting 20:09:15 I moved it to Queens because I thought we already had 2 goals and stevemar made me realize 3 goals might be too much 20:09:20 * jroll loves this goal 20:09:30 I don't think the amount of work is huge for this one 20:09:43 but I'm probably missing something, specially for some projects (maybe neutron) 20:09:44 EmilienM: do you think it could be a Pike goal if the tempest plugin stuff is deferred / abandoned ? 20:09:46 EmilienM: fwiw, I like this goal and I'd go as far as saying that it'd be great to do it in Pike and hold tempest for Queens 20:09:56 ttx: yes, it would be doable I think 20:09:56 as many of you know keystone was one of the first to move to mod_wsgi + apache and ditch eventlet, its one of the best things we've done as far as operators are concerned 20:09:58 we could leave this one pending if the back up plan for tempest related goal doesn't pass. 20:10:04 flaper87: ++ 20:10:13 stevemar: yes exactly that 20:10:14 We need more feedback on it though 20:10:15 stevemar : ++ 20:10:19 ttx +1 20:10:34 so, I actually think because of some of the apache port binding weirdness, we actually need to get off appache for this to really work 20:10:43 and explore other wsgi runtimes 20:10:49 so, for next week folks can give feedback on wsgi goal, so we have a backup ready in case the other one doesn't make it 20:11:02 EmilienM: I'm surprised that Glance can't be deployed like you want but at the same time, I am not an expert ;) 20:11:02 EmilienM: could you try to gather more PTl feedback on it, just in case we end up needing it ? Ideally we would choose the goals before end of month 20:11:05 sdague: what weirdness, specifically? 20:11:12 making it webserver agnostic seems generally fine to me 20:11:19 sigmavirus: I'll need to investigate more 20:11:20 does this goal need to be specifically about apache? or just "some" wsgi server? 20:11:24 ttx: yes, it's on my list. 20:11:27 jroll: in order to separate out service logs you need a stanza where you can do it 20:11:31 OK good 20:11:36 fungi: yes that's the Goal 20:11:40 which turns out to be a vhost 20:11:45 i think the wording said any possible web server 20:11:55 fungi: only thing is devstack use apache, so for testing, we'll keep using apache 20:11:55 well sorry, that may be too broad :) 20:11:55 which means we still have to bind all the weird ports 20:12:08 sdague: you can still have the python do the logging aiui (rather than rely on apache) 20:12:13 EmilienM: in all cases it doesn't hurt to have a backlog -- it gives a chance to teams that are a lot behind to get an early start 20:12:15 I think it's clear in the goal that you can use any webserver 20:12:26 ttx: indeed 20:12:28 dtroyer: it's already about just exposing a wsgi app that any wsgi-supporting thing can use 20:12:28 sdague: ah right 20:12:28 * jroll plugs nginx/uwsgi 20:12:30 clarkb: possibly 20:12:31 dtroyer : the original idea was to do whatever devstack is doing, but once you have a WSGI app it should work with any server 20:12:35 I feel like Python 3.5 is easier to pass now because we mentioned it last cycle 20:12:47 anyway, the point is that the apache model turns out to be kind of clumsy 20:13:03 we also need to consider this goal might affect small projects with lower bandwidth 20:13:06 and would rather not have everyone put in the effort on the odd work arounds there throughout the community 20:13:17 #info trying to address concerns in split-tempest-plugins, and gathering feedback on deploy-api-in-wsgi in case we need it as a backup plan 20:13:18 also for completeness you can also switch vhosts on name rather than poirt 20:13:23 in order for this to be a well-defined goal, we need to pick *one* target, even if we do end up supporting others 20:13:25 sdague: ++ 20:13:29 otherwise we'll have a lot of reinvention 20:13:32 nova.openstack.test:443 vs neutron.openstack.test:443 20:13:42 dhellmann: ++ 20:13:49 clarkb: you can, but then you have to distribute dns in your dev env 20:13:59 sdague: which we already do 20:14:03 to make multinode testing work 20:14:04 so if there's an issue with apache, let's use another service, but let's definitely specify one 20:14:09 clarkb: not for users 20:14:13 clarkb: this is more than CI 20:14:20 this has to work for developers as well 20:14:28 yeah, I don't do dns 20:14:41 ok, just want to point out options here for completeness 20:14:48 * fungi notes we have an entire openstack service devoted to dns ;) 20:14:49 apache doesn't actually prevent you from doing this they way you want 20:14:51 I am all in favor of us getting here, I just wanted to raise specific concerns 20:15:03 I think it's solvable but doesn't want to dig into details here 20:15:05 clarkb: it sort of does given the constraints of working deve environments 20:15:07 s/doesn't/don't 20:15:08 let's elaborate more on this things on the review 20:15:11 sure 20:15:15 we could also decide that it's useful to have those logs combined *shrug* 20:15:27 pls no 20:15:30 sdague: please add it into the review 20:15:36 since this goal is more "operator focused" can we add some to the review? like mfisch? 20:15:40 log overload already, with them separate 20:15:52 it seems like a viable second pike goal, assuming enough projects are already close to doing it 20:15:56 stevemar: I sent an email to openstack-dev and openstack-operators already 20:15:59 yes, please all feed back to the review so that we have all the cards on the table for next week 20:16:39 Anything more on that topic ? Any other goal that could serve as a Pike contender ? 20:16:50 EmilienM : you may want to highlight the fact that we're now considering this for pike, not queens 20:16:55 dhellmann: +1 20:17:03 dhellmann: yes, I'll update it 20:17:30 ttx: i'm done with this topic. 20:17:50 OK, good! 20:17:54 #topic Introduce assert:supports-api-compatibility 20:17:58 #link https://review.openstack.org/418010 20:17:59 while we're on goals, there has been a lot of interest in the quota goals, so it would be good for someone to line up to manage that for queens or r* 20:18:11 mtreinish is at LCA so isn't around to present this 20:18:18 I see it as a continuation of mordred's rant a few cycles ago 20:18:26 that we could just say that we won't ever break an API 20:18:52 making it an assert tag is a good way to achieve it 20:19:15 timing makes this feel like it's an answer to the glance/community images debate, heh 20:19:32 The review is pretty dry for the moment, what are your thoughts on that ? 20:19:48 (only a few TC members commented so far) 20:19:56 how would the TC police that tag? 20:19:58 does the "API change guidelines" change? 20:20:07 there was some pushback to the idea of having microversions as a goal because some folks think it's not a great approach. do we want to encode that answer in this tag? 20:20:15 bswartz: we don't need to. projects decide whether they want the follow the rule or not 20:20:19 bswartz : there's a requirement for a test job 20:20:23 bswartz: same as for most of our tags, expect the community to self-regulate and propose addition/removal of it with justification 20:20:28 bswartz from the requirements it was my understand that there be a test job 20:20:37 ah, misunderstood the question 20:20:49 how I read bswartz question: how does the tc validate that the api tests cover enough to be meaningful 20:20:49 Is it useful to know that that the api-wg does not like the api change guidelines? 20:21:00 so if a project says they're following the tag, but then they don't, there's a way to catch the mistake before something bad happens 20:21:01 cdent : yes 20:21:21 cdent: it would be more useful if the api-wg changed the guideline then 20:21:22 They are too easy to use as a false metric where following the letter of the law becomes more important than the spirit of helping users have a good (long term) experience 20:21:27 sdague ++ 20:21:37 sdague: the api-wg has only just recently realized how little they liked the guidelines 20:21:45 also, usual excuses about timelines etc 20:22:14 and also it is rather clear, based on the experience of the past couple of weeks, that the members of the api-wg are not necessarily representative of the some of the common feelings on this topic 20:22:15 we have an api change guideline to go off of. anyone is welcome to improve it. 20:22:17 so it is a bit challenging 20:22:23 we probably want to wait until that's worked out to approve this tag definition, then, because otherwise the requirements for the tag will change out from under teams 20:22:38 dhellmann seems reasonable 20:22:47 * edleafe missed his calendar alarm and shuffles to the back of the room 20:22:52 dhellmann: +1 20:22:54 maybe someone can start a ML thread about it? 20:22:54 * mordred hands edleafe a pie 20:22:59 ++ dhellmann 20:23:00 dhellmann ++ 20:23:11 mordred: mmmmmm... pie! 20:23:13 pie ++ 20:23:21 anyone wanting to sub for mtreinish and start a thread ? 20:23:46 ideally someone who wants that tag to exist :) 20:23:48 cdent : please do leave a comment on the review, if you haven't already 20:23:48 are we talking about a thread about the tag or a thread about the need to change the guidelines 20:23:57 dhellmann: yeah will do 20:23:57 cdent : a bit of both 20:24:09 if the latter, I can certainly do the latter 20:24:10 ttx: so I think the ML thread really is about the api-wg not liking the guideline 20:24:15 cdent : that's a good start, thanks 20:24:22 sdague: Ah, misunderstood, ok 20:24:29 k, I'll do that tomorrow 20:24:37 because, I also do wonder about the api-wg opinion being representative of the projects, and a ML thread would help there 20:24:55 sdague: ok so a more fundamental "is it a good idea at all" 20:25:41 thanks cdent 20:25:47 well, honestly, https://review.openstack.org/#/c/418010/2/reference/tags/assert_supports-api-compatibility.rst seems like exactly what many of our users have been asking for 20:26:06 and I agree that it lines up really strongly with mordred's rants on this subject 20:26:24 I think compatibility is a good idea, I have no problem with that. The issue is with some of the metrics in the guideline 20:26:29 * thingee agrees strongly that mordred rants 20:26:39 yes, can't wait for mordred to reapply that rant to the thread 20:26:39 * mordred rants 20:26:50 * ttx has been missing mordred's rants lately 20:27:08 OK, anything more on that topic ? 20:27:12 cdent: so is it more accurate that the overall guideline spirit is fine, but there are details the api-wg would like to refine? 20:27:15 * mordred has to withold rants occasionally so that people enjoy their return 20:27:36 I'm trying to figure out if we're going from round earth to flat earth, or round earth to elipsoid earth 20:27:58 sdague: I need to review them in detail, but I like they were being applied in the absolute rather than in sprit and that (sorry to be so squishy) felt unfortunate 20:28:19 * fungi observes that the earth is not a perfect ellipsoid, but in fact slightly eggish 20:28:19 s/I like/I feel like/ 20:28:51 fungi: eggs are tasty 20:29:02 It's akin to the way if you don't match metrics as a hospital in the NHS, they take away your funding. 20:29:05 Backwards 20:29:23 cdent: which is more about interpretation than content 20:29:28 * cdent will to make this morass much more clear in the email tomorrow 20:29:35 ok, anyway, ML list might clarify 20:29:42 cdent: https://en.wikipedia.org/wiki/Goodhart%27s_law 20:29:50 sure, the content needs to be better about setting an interpretational context 20:30:03 mordred: yes, that, thanks 20:30:26 ok, let's move on, funny topics in open discussion 20:30:31 mordred: sure, but the corolary is that there have been constant calls that things weren't clear enough so they should be written down 20:30:42 and if now writing them down is wrong... *shrug* 20:30:57 sdague: yes, that's slightly disappointing 20:31:23 sdague: oh - no, I totally think we should write them down 20:31:44 at the end of the day... "be a reasonable human being" still has to be assumed here. Nothing, written or unwritten, works if that's not there. 20:31:47 aren't we just talking about being clear when we do write them down? 20:31:49 sdague: just agreeing that we need to make sure to contextualize such that it's clear that there is a spirit that can be more important than the letter 20:31:56 and writing down what we agree on, not just what the author agrees on? 20:32:02 dhellmann: yah 20:32:27 * cdent has not intended to set off such a stir 20:32:29 if we currently have places where people are chasing the wrong thing, we just need to adjust to make it clear what they should be chasing 20:32:37 mordred: sure 20:32:39 It was just this: the guidelines need review and revalidation before we depend on them. 20:32:54 cdent : totally 20:32:55 cdent: said this way, kinda makes sense 20:32:58 cdent: ok. I think it's always fair to revisit things 20:33:00 right, let's just get everything lined up before we start sending folks off in the wrong direction 20:33:11 (I've said as much in my comment on the tag review and will say as much in the email) 20:33:13 but I think it's also important to realize people are already depending on them 20:33:17 they've been around a while 20:33:30 ok, so let's do that in the thread, and investigate how we'll actually test/verify that 20:33:50 that tag isn't exactly time-sensitive so we can take the time to do it right 20:34:00 #topic Open discussion 20:34:07 * Date/location for Board+TC workshop on OpenStack Futures 20:34:13 As you know we decided not to overload the PTG with a Board+TC meeting 20:34:21 which I think was a sane decision given how busy that week is gearing up to be 20:34:31 To make progress on that strategy topic, the Board is now proposing a separate 1- or 2-day workshop, sometimes in March 20:34:38 One date/location they are floating is Boston the week of March 6th 20:34:47 An alternate date/location would be to place it the day before the Ops Meetup in Milan (Italy), week of March 13 20:34:58 I tend to prefer the latter because I can combine events to justify the trip, and it's further away from the Atlanta travel 20:35:03 also we can visit flaper87 20:35:06 Boston location works for me! 20:35:18 As crazy as it sounds, I won't be around on the OPs mid-cycle 20:35:20 :( 20:35:30 flaper87: dude! 20:35:33 flaper87: what? 20:35:34 so, I prefer the 6th 20:35:40 boston would be better for me 20:35:44 ok, let me doodle it to check 20:35:45 yeah, another trip got in the middle 20:35:46 same ^ 20:35:47 :( 20:35:52 ttx: can we vote maybeN 20:35:54 just a sec 20:35:57 sounds like we have time 20:36:08 yes, setting up a doodle for a slightly more complex answer scheme 20:36:11 Actually, I'm out from the 8th 20:36:27 wouldn't the 7th make sense for boston too? 20:36:44 i should be able to manage a couple days in boston. not as convenient as some places i can get direct flights, but it's still reasonably nearby that i can't complain 20:36:59 just to interject - the 6th was a target to shoot at 20:36:59 wow that thing sucks 20:37:07 Let me try a startvote instead 20:37:11 what's happening in boston that makes that a good location/date? 20:37:34 oh wait, march, not may... 20:37:52 Boston was simply East Coast - figured it easy for TC members to get to ; my understand is most TC is on East Coast 20:37:59 dhellmann: yeah, same question 20:38:10 AlanClark : ok, I was just curious 20:38:26 esp. given the attachment to the ops meetup for the other date 20:38:41 what about late March ? After the 18th ? or early april ? 20:38:43 One thing to consider though is that a lot is happening in the US this year, especially with two PTGs there 20:38:48 ttx: did you send a doodle already on ML? I probably missed it 20:39:00 EmilienM: think he's creating it 20:39:06 no the doodle is not playing location/date game well 20:39:36 maybe we can first pick a place and then a date or vice-versa? 20:40:45 Oh, there is alaso Berlon the week of March 27, colocate with CloudNative Con 20:40:49 Berlin* 20:41:07 yeah, that'd be perfect for me since I'll be there :P 20:41:24 Will observers be permitted? 20:41:26 either location is fine with me, but the later into march we go the more likely it will overlap with my as-yet-not-locked-down holiday plans. 20:41:40 https://framadate.org/bK8ziU1mhzjThdih 20:41:44 yah - so far I'm fine with any of these dates 20:41:50 not that it should be planned around me, of course 20:42:17 and happy to do boston, berlin, or whatev 20:42:22 One issue for me is that I'm /also/ scheduled for another round of training in Ann Arbor 20:42:42 ttx: will it be a 1 day thing? 20:43:20 I would make it a 2-day thing to justify travel 20:43:33 I would like to do 2 if possible 20:43:52 mmh, ok. 2 might not work for me if we do it on March 6th so I'll put maybe 20:44:42 done 20:45:03 OK, people can continue to vote and I'll collect the results and post on the ML, circle back to Alan 20:45:19 next topic was: 20:45:21 * Base services 20:45:30 The ML discussion on depending on Barbican has some interesting insights 20:45:31 yes pleaes 20:45:38 I think we (arch-WG and TC) need to move on with defining "base services" and start thinking adding more 20:45:48 I'll push a thread on this this week 20:46:08 because frankly, reinventing the wheel locally a dozen times to not have a dependency sounds a bit silly 20:46:30 especially with something as easy to get wrong as crypto 20:46:50 most of TC is US/Canada based, it would be odd to go in Europe. Maybe Board is mostly Europe based? 20:47:20 EmilienM : I think the idea is that they may be going to that ops meetup as well 20:47:31 dhellmann ++ 20:47:31 sure, though I think Duncan's point is pretty valid too, getting crypto wrong is not just about the crypto code itself, but how it's used. And there are some big usage questions right now. 20:47:41 EmilienM: board is pretty split between asia, europa and usa now 20:47:56 jbryce, dhellmann: fair enough 20:47:57 sdague: if Barbican is not the right solution, then we need to express that 20:48:07 and why 20:48:11 ttx could you add Berlin to the poll. Board: 5 Asia, 4 EU, rest North Amer 20:48:20 base service: http://git.openstack.org/cgit/openstack/arch-wg/tree/proposals/base-services.rst 20:49:00 ttx: the why part I think is important 20:49:09 ttx: especially if it's actionable 20:49:38 AlanClark: Added 20:49:48 AlanClark: you could reuse it for the Board too :) 20:50:15 ttx: great idea 20:50:59 it also sounded like expressing that (and why) may not fix barbican without finding more contributors 20:51:07 thingee: so... to be clear, oslo.db doesn't mean you support other dbs, db migrations definitely can (and do) have dbisms in them. 20:51:14 jbryce: yeh, that's how I read the thread 20:51:31 jbryce: agree 20:51:33 there are gaps, they are known, now by more people 20:51:47 but closing them isn't really on anyone's radar 20:52:11 on the other hand, projects reimplementing crypto primitives and tooling multiple times when those same people could contribute that same work to barbican could also be hypocritical 20:52:35 ttx: milan is on that poll twice now? 20:52:47 I think either barbican is good and everyone should use it for that purpose, or it isn't suitable for $reasons and we shoudl all know the reasons so we can have a discussion about what projects needing that functionality should do 20:52:49 i like the idea of thinking out what other services would be really useful to have as “base services” and thinking about it even broader than just services that there are openstack options for. as someone in the thread pointed out, starting with some basic assumptions early on (rdbms, mq) did help…those were not things that were all built in openstackland 20:53:05 each project implemeting crypto individually and not coordinated is certainly the worst outcome 20:53:13 sdague ok SpamapS ^ 20:53:15 jbryce: ++ 20:53:53 dhellmann: i only see one milan, but the field orders got moved around 20:53:55 mordred: +1 on multiple crypto == bad 20:54:10 jbryce: in ad-hoc discussions I've had people ask me about things like statsd/graphite/elk and similar things, for which we do not have a coordinated answer 20:54:13 fungi : and now reloading does show that 20:54:26 fungi: maybe, except the primary concern is actually the barbican interface relying on a keystone token 20:54:29 (and for the record, I've heard both "why don't you have an opinion" AND "please stay out of having an opinion" 20:54:39 fungi: I had to add a column to modify the "Milan" choice to include ops meetup colocation 20:54:43 fungi: should be all set now 20:54:54 because the keystone token actually isn't secure enough for the kinds of operations you want to do with the secrets 20:55:02 sdague: sure, maybe the solution is for the people who have a different need to collaborate on something not-barbican which has the alternate design they need 20:55:03 mordred: that means "why don't you have MY opinion" :) 20:55:14 edleafe: yup 20:55:25 Last thing I wanted to cover in open discussion was... 20:55:31 * Next steps for Golang 20:55:33 most use cases I've heard from barbican devs is that they want to be able to get a token for a specific secret (instead of all of them within a project) 20:55:35 From flaper87's document it feels like someone needs to formally push step 1 20:55:43 "Use case analysis" 20:55:47 flaper87: Or should we consider that done ? 20:56:13 I think one specific use case is done, not sure if that covers the general case though 20:56:33 do we need more than one use case to get the ball rolling on the rest of the process? 20:56:45 yes, we need that first phase to be officialized for golang 20:56:53 https://governance.openstack.org/tc/reference/new-language-requirements.html#step-1-use-case-analysis 20:56:56 flaper87: are you working on it ? 20:57:09 or waiting for someone else to pick it up ? 20:57:20 I'm not because I think other folks have a better understanding of the use case for golang than myself 20:57:32 so, hoping someone from the swift team can help with this 20:57:35 (my question about needing more than one use case was in response to dtroyer) 20:57:39 or anyone interested, really 20:57:47 flaper87: it sounds fair. 20:58:04 should we... trigger that in other folks ? 20:58:07 fungi: sure. I don't think we need more to start, or I should say I didn't wait for that to start… 20:58:24 ttx: I tried but I'll be more agressive this time 20:58:31 or maybe dims can take it 20:58:31 but I also have a want for it in a place that doesn't fall under this specific guideline (a non-service project) 20:58:39 * flaper87 will write to the mailing list to announce this has merged and to request for volunteers 20:58:50 flaper87: +1 20:58:50 has been merged* 20:59:03 * thingee whispers to ttx that he has an item that wasn't posted 20:59:05 ack i can help with that 20:59:32 dims, sdague added one option to the poll (Berlin) in case you want to file how much you love/hate it 20:59:34 dims: i'll send the email anyway, feel free to "o/" there too :) 20:59:48 OK, last minute... Anything else, anyone ? 20:59:52 o/ 20:59:54 flaper87 : will do 21:00:01