20:02:48 #startmeeting tc 20:02:49 Meeting started Tue Jul 8 20:02:48 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:53 The meeting name has been set to 'tc' 20:02:55 Our agenda for today... 20:02:58 Hi 20:02:59 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:12 #topic Core Capabilities TC scoring 20:03:27 We still have to finalize our answer for the Havana core capabilities "TC" columns 20:03:30 i think we're about ready for another revision here. dhellmann said he'd do it post meeting 20:03:42 ok 20:03:45 zehicle: it might be worth reading over the comments ... there's a few issues with capability defitions 20:03:52 definitions that is 20:03:52 yeah, I have the update ready but thought I would make sure there wasn't other feedback first 20:03:54 I commented about the meaning of each column, based on Rob's post: 20:04:00 #link http://robhirschfeld.com/2014/05/01/defcore-capabilities-selection/ 20:04:11 #info "Complete": 0 if the capability test is configuration-specific, 1 otherwise 20:04:20 #info "Stable": 0 if the capability has been there for less than 2 releases, 1 otherwise 20:04:29 #info "Future direction": 0 if we plan to deprecate that feature in the near future, 1 otherwise 20:04:30 thanks again to russellb for digging into the meanings on the capability names 20:04:36 dhellmann: np 20:04:36 ok 20:04:38 Any specific row you'd like to discuss here ? 20:04:50 or should we just iterate on hte review ? 20:05:01 there's some start-up wiggle that you have to accept 20:05:12 Review link: https://review.openstack.org/100722 20:05:18 we wrote them as if it was a going thing and accepted that iteration 0 would have null for previous pointers 20:05:24 i think we can iterate on the review 20:05:32 zehicle: what's the process for removing a capability? when nova-network is deprecated, for example, some of the ones like compute-security-groups might change or go away. how does that work? 20:05:43 s/when/if/ 20:05:48 :) 20:06:06 dhellmann: realistically it probably doesn't change. We've said there needs to be parity for those interfaces to deprecate 20:06:08 it should be marked as not future and then raised to defcore 20:06:18 ideally, we would not make things that are depricated core at all 20:06:39 BUT we are trying for interop so stability is key 20:06:51 zehicle: capability issues i noticed: test for compute-auth doesn't actually test auth. compute-security-groups includes a test not related to security groups. compute-admin-fixed-ips i don't think is an admin API. 20:06:53 part of the rationale for a small set 20:07:04 russellb, ok 20:07:05 i didn't review all of them, just the ones we were tweaking 20:07:23 right, that's my point -- if we leave this in now, and decide later that it's silly to proxy requests to neutron through nova (as a technical decision) how hard does the capability make the change from a policy perspective? 20:07:29 we very very much want feedback about the tests & capabilities 20:07:43 dhellmann: this is updated on a per release basis is my understanding 20:07:44 it was not our plan to have defcore own that - it feels like a technical item to me 20:07:56 dhellmann: this is havana, so don't think it's a big deal, since this trails the code 20:07:58 BUT I've had that feeling before and found the TC did not agree 20:07:59 zehicle: but if the API that test is looking at goes away... 20:08:17 russellb: I'm just trying to understand the process, and how long things are expected to stay around. 20:08:23 dhellmann: ok 20:08:27 these are good questions 20:08:38 russellb: I'm not arguing that we shouldn't mark those items 1 for now, just being careful :-) 20:08:40 we expect changes release to release 20:08:47 we;re not trying to make a lifetime standard 20:08:59 so we could say that icehouse doesn't have that feature at all, and no one would be upset? 20:09:01 OK, I think we have enough to iterate on the review -- we just need to go fast 20:09:01 russellb: further question, do we want admin APIs in defcore? I always get a mixed message on them from folks in terms of the guaruntees that come with them. 20:09:03 ideally, we should add more than remove 20:09:06 (hypothetically) 20:09:20 sdague: they automatically exclude anything that is an admin API right now in their scoring 20:09:22 yes, well, adding is the easy case 20:09:26 russellb: ok 20:09:35 sdague, no. admin API are not considered core for now 20:09:44 sdague: that is an interesting question in teh context of our discussion about testing admin APIs with tempest last week 20:09:49 zehicle: good to know, thanks 20:09:51 (which raises an issue since tempest requires admin access to test non-admin APIs) 20:09:52 sdague: i was saying something they called an admin api isn't one 20:09:54 I've updated the review with feedback from russellb and vishy 20:09:55 devananda: yep, that's what I wanted to bring it up. 20:09:58 russellb: sure 20:09:59 dhellmann: great thanks 20:10:20 russellb: honestly, those sorts of issues are things we should probably fix in tempest as 'upstream' for this 20:10:32 zehicle: fwiw, that rules ironic out of defcore since it only presents an admin-facing api 20:10:33 devananda, we are still trying to score the admin API because it's useful information 20:10:38 damn germa s 20:10:40 +n 20:10:49 zehicle: ack 20:10:59 and whether or not it's included really isn't our concern here 20:10:59 devananda, there are several things that are out. it;s about interop 20:11:06 we're providing technical answers in this review 20:11:09 zehicle: indeed. just checking expectations :) 20:11:17 if you cannot run both public and private using the core then it's not core (for this pass) 20:11:37 we do expect that there will be broader sets in the future. this pass is the min 20:11:51 ok, shall we move on? 20:11:55 that's exactly why I want to make sure we keep scoring the admin apis 20:12:03 ttx: that's all I had 20:12:09 +1 on latest revision dhellmann just posted 20:12:15 I'm happy to field questions on the defcore list or 1x1 as needed 20:12:30 we'll update the definitions to clarify if needed 20:12:32 zehicle: Once we are done with this cycle we'll discuss how to effectively do it for the others 20:12:42 +1 20:12:42 ok, moving on 20:12:46 #topic Election behavior guidelines 20:12:55 We still have two proposals for addressing that issue: 20:13:01 * A resolution on standards of behavior during elections (https://review.openstack.org/100445) 20:13:07 * Adds a resolution addressing expected election behaviour (https://review.openstack.org/98675) 20:13:14 * ttx quickchecks for recent changes 20:13:40 At this point the main differences are: 20:13:45 my understanding from last round was we were about to discuss to whom the tc wanted me to report 20:13:49 anteaya's proposal insists on the reporting procedure and spelling out the potential consequences 20:13:52 and then we ran out if time 20:13:58 eglynn's proposal insists on the public call-out, includes a "pledge" part but also mentions the CCoC violation process as an in extremis solution 20:14:08 At this point I could go with both -- I like that eglynn's proposal mentions both options, while I still dislike the pledge part 20:14:20 However I think they are using different words to express the same thing, at this point... 20:14:23 should we try to converge on a single one this week? 20:14:28 i'm strongly negative on the pledge part 20:14:32 or we should pick one depending on how strong we want our tone to be 20:14:39 for those who don't know 20:14:46 I have had to use a pledge in teh past 20:14:57 and the pledge was in the person's own words, not mine 20:15:07 and was in their handwriting, not copy/paste 20:15:14 this was in the case of a lost ballot 20:15:18 jeblair: could you explain why? 20:15:31 and the person pledged to not vote twice if they got two ballots 20:15:34 I don't like it eiter but I think you'll have stronger arguments than I have 20:15:37 I like a lot of the preamble in eglynn's, but I agree with jeblair on the pledge and I don't think the "public shaming" aspect is going to be a good solution long-term. 20:15:48 so I do use pledges, but boilerplate isn't helpful 20:16:06 I'm strongly negative on quickly escalating outside of the technical community 20:16:17 and putting election officials in a very difficult position 20:16:23 markmc: to whom would you like me to report 20:17:03 anteaya, eglynn's latest draft suggests that election officials should only be used for advice and guidance on how to resolve 20:17:12 ttx: we haven't seen any bad acting from candidates themselves, so i think it distracts from the actual problems we're responding to. but also, i find forced pledges disingenous. i find it distasteful that i might be required to say something i might not beleieve in. 20:17:17 resolution being discuss publicly or escalate to ED 20:17:17 advice and quidance to whom? 20:17:22 the reporter 20:17:34 I'm foggy 20:17:37 maybe a version that had the good preamble, details about behavior for campaigners and candidates, and a reporting procedure to the TC (?) would be a reasonable compromise? 20:17:43 who conducts an investigation? 20:17:44 TBH the pledge isn't really the key aspect of my proposal, rather it's the promotion of a shared value-system in the community 20:18:21 anteaya, preferably an "investigation" isn't needed - if it is, it's the ED 20:18:33 what you also might not know was that I wanted to take this to the ml when it happened in the spring 20:18:35 eglynn: you could say the same thing without the "forced" pledge 20:18:42 the person I talked to didn't want to do that 20:18:58 eglynn: saying that any candidate shall respect the expected behavior, or something 20:19:03 markmc: great, then that is what I'm for as well 20:19:27 ttx: sure, if the forced nature of the pledge raises freespeech hackles, I could work it out of the proposal 20:19:30 since I didn't want to be the one getting the response from the person accussed of violations 20:19:39 anteaya, we'd now be setting the expectation that discussing publicly is the preferred first approach 20:19:41 that was a comment on the patch I was asked to add 20:19:53 I dis agree with taking it to the ml 20:19:54 I like that anteaya's proposal has a clear escalation procedure, but I can see how it can appear to ostrong as the only mechanism 20:20:09 I think that public discussion is a reasonable expectation 20:20:15 since that might not bring a resolution in the time to retain the integrity of the election 20:20:25 I think that part of the problem in the spring is we didn't have anything documented 20:20:40 I suggested taking it ot hte ml 20:20:51 why was that not accepted then but is fine now 20:20:53 markmcclain: I expect any of the tewo proposals we have today to solve that 20:20:56 what has changed? 20:21:11 ttx: agreed..writing something down is good 20:21:29 anteaya, what would have changed is that we'd have set the expectation that discussing publicly is the preferred first approach 20:21:39 at some point it has to become public 20:21:48 yes, it does 20:21:57 it should become public, but I don't think that's the *first* step, is it? 20:21:57 that the issues last time around never became public is unsatisfactory 20:22:01 they are getting pretty close. If anteaya adds public discussion and eglynn removes te pledge they would be pretty similar 20:22:03 and if you want it happening during the election, that is up to the tc 20:22:25 for genuine mistakes, I'd much rather a calm, adult conversation rather than the result of a formal investigation 20:22:28 I see it potentially being disruptive to other elections running concurrently not involved in the event 20:22:30 damn germans� 20:22:36 ttx: :) 20:22:59 but that still doesn't solve markmc concern with mine 20:23:00 markmc: agreed - and a 1:1 with the election supervisor may be a better way to have that than posts to the ML 20:23:07 since I am still reporting to the ED 20:23:21 and I would like to hear whom I am to report to, if not the ED 20:23:44 markmc: I think that part of the problem with surfacing the issues publicly is that there wasn't any set expectation to protect either side 20:24:18 yeah, honestly, if i got a weird campaign email, i'm not sure the first thing i'd want to do is post to the ml; i might want to chat with someone first 20:24:27 jeblair: +1 20:24:34 markmcclain: what sort of protection would be required, anonymity? 20:24:36 I have seen the negative effects on a community where taking grievances directly to the mailing list was considered normal. We do not want to do that. 20:24:43 * ttx shall stop watching the game now 20:24:45 eglynn: mainly process 20:24:47 and people did ask me questions, but I never got any facts 20:24:53 just interpretation 20:25:00 jeblair, and if the sender apologized and you felt that had resolved the issue - why take it further? 20:25:02 both sides should have an expectation of both behavior and ways to report 20:25:07 without being able to arrive at my own 20:25:15 the last thing we should do is to make things up on the fly 20:25:20 jeblair, which is what happened in the case I'm aware of 20:25:42 jeblair, I'm very afraid of turning that into a rapid escalation 20:25:50 why rapic 20:25:52 d 20:26:00 why do you think this would be rapid 20:26:03 ttx: probably a good thing you stopped watching ;) 20:26:18 markmc: i'm not sure it's the sender i'd want to talk to. i don't want to get on the bad side of someone who feels it's okay to send campaign spam. 20:26:34 anteaya, you're talking about a resolution before the election finishes, right? 20:26:56 markmc: or decison that sees an election ending and a new one starting 20:27:00 jeblair, meh; if we can't as a community reinforce our culture amongst ourselves ... 20:27:06 if a decison can be reached in that time 20:27:19 but if as you say this was a genuine mistake, with apology 20:27:31 do you feel I would reach the same conclusion as yourself? 20:27:43 do you feel I can recongize a genuine mistake? 20:28:08 anteaya, let's not make it about you - I worry that not all election officials would be even-handed 20:28:10 markmc: we're not all comfortable being confrontational. and in public. i'd like to keep the door open to people that might want to help our elections stay clean but whose first inclination is not to start a kerfufle on the mailing list :) 20:28:14 anteaya: you might not always be our election coordinator, so we shouldn't make this about *you* personally 20:28:27 jeblair: +1 20:28:36 jeblair: +1 20:28:40 markmc: fair enough but I would hope that future election pairs would be even-handed 20:28:40 setting up a process which could turn a genuine mistake into a nasty situation ... 20:29:13 dhellmann: no I agree, but future pairs of election officials 20:29:13 markmc: do you think it's more likely the TC could avoid that than an individual election official? 20:29:26 dhellmann, yes, very much so 20:29:44 honestly, I'm not sure I even have a strong lean at this point. I can see both of these approaches. I do get concerned though if we aren't actively reenforcing our culture, even if it means some conflict. 20:29:49 dhellmann, the only issue is the weird situation with half of the TC not having a mandate 20:29:50 ok, so let's have the election official report to the TC and then issue a report to the ML 20:29:59 sdague: +1 20:30:12 dhellmann: I can do that 20:30:14 markmc: true, but half does 20:30:17 or half the tc 20:30:24 or the tc delegation 20:30:36 or however the tc wants to identify the group 20:30:49 personally I would prefer it 20:31:01 then if the tc wants, the tc can report to the ED 20:31:01 the full tc, including those up for re-election, to avoid having 1/2 stage a coup :-) 20:31:04 and I'd hope the TC would use it as a "teachable moment" as eglynn puts it 20:31:13 dhellmann: I'm fine with that too 20:31:15 even if a mistake, discuss openly so everyone learns 20:31:30 yes, I would lean heavily toward dealing with it quietly unless it was an extreme case 20:31:33 dhellmann: I would just need timeframes, this group prior to this date, this group after this date 20:31:56 dhellmann: +1 20:31:56 perhaps leaving names out of the public discussion, for example 20:32:13 I'm for reduction of gossip 20:32:13 suggest this at one point - http://paste.openstack.org/show/85709/ 20:32:16 in the review 20:32:20 get to the facts, address the facts 20:32:27 gossip just hurts everybody 20:32:59 anteaya: the TC is the TC until the elections are complete, no? 20:33:04 markmc: sounds good 20:33:16 dhellmann: half of it is running for election though 20:33:37 so I like the idea that the half that still has 6 months to go would consider te complaint 20:33:38 dhellmann: yeah, see that is where I need some timeframes 20:33:50 ttx: ok, I can go along with that 20:34:02 markmc: I'm fine with the paste 20:34:09 markmc: I like what you have in that pastebin 20:34:32 who's going to work on bringing these 3 things together? 20:34:40 dhellmann: do you want to? 20:34:47 * dhellmann should have seen that coming 20:34:51 sure, if you like 20:34:51 hehe 20:34:56 dhellmann: thanks 20:35:01 heh 20:35:05 dhellmann: I can work with you too 20:35:08 do we want a third proposal? 20:35:11 markmcclain: thanks 20:35:27 I like most of markmc's proposal, except for the optional redaction of names 20:35:36 dhellmann: or iterate on one of the others, your call 20:35:44 dhellmann, no harm in another proposal, bring elements of each together 20:35:48 ok, I'll probably do a third just to keep it clear 20:35:51 dhellmann: do as you see fit, as long as someone is willing to report behaviour that is questionable so it doesn't perist, I'm happy 20:36:00 dhellmann: famous last words 20:36:11 ttx: don't you have a game to watch? 20:36:13 eglynn: because you don't want them redacted, or you don't want it to be optional? 20:36:26 dhellmann: somehow the germans stopped scoring at 5-0 20:36:46 zaneb: both ... I'd prefer to avoid speculation and rumor as to who was involved 20:36:56 ttx: Je suis désolé 20:37:37 ok, ready to move to next topic ? 20:37:55 * markmc is 50/50 on redaction - wouldn't want "shaming", wouldn't want rumors, would hope we can be adults, yet names aren't required for it to be a teachable moment 20:37:56 ttx: I think we've covered this one 20:38:01 ok then 20:38:03 #topic Other governance changes 20:38:11 * Resolution requesting designated sections from projects (https://review.openstack.org/100675) 20:38:17 I suspect we should abandon this one now, let me know if you disagree 20:38:26 * Add translation support requirement (https://review.openstack.org/97872) 20:38:31 I agree 20:38:59 There seems to be some guidance needed as to the type of testing we require 20:39:11 I tried to comment to that effect 20:39:14 yes, do we need to write up the formal response or is the log from the last meeting enough? 20:39:27 oops, that was about the designated sections :-) 20:39:58 dhellmann, russellb's summary blog is plenty clear IMHO 20:40:04 dhellmann: I don't think we need to write up that we wn't make a resolution on something... But if you think that's useful, we could 20:40:10 markmc: ok, I think I missed that so I'll look for it. 20:40:25 ttx: nah, I wasn't sure what the defcore committee wanted 20:40:26 unless anyone objects to how it characterizes what went on? 20:40:36 http://www.openstack.org/blog/2014/07/openstack-technical-committee-update-july-1/ 20:41:00 is sdague around? 20:41:08 ttx: yes 20:41:10 #link http://www.openstack.org/blog/2014/07/openstack-technical-committee-update-july-1/ 20:41:36 sdague: it looks like Andreas and the i18n folks want more... precision of what kind of tests we want 20:41:41 if there's a test, it should be a gate test, not a periodic one 20:42:02 russellb: good write-up 20:42:21 jeblair, you basically need to run everything in every locale 20:42:24 jeblair: I think that's probably a different discussion 20:42:29 I just want the blatant hole covered, but yeah, I agree that if it's not gating it's likely to be ignored 20:42:35 dhellmann: thank you 20:42:42 jeblair, running on just the translation import jobs might do it 20:42:45 sdague: sure, but it was a question actually asked in the review :) 20:42:48 ttx: the problem is, it's going to be ignored in the gate anyway 20:42:57 people will recheck grind on it 20:43:01 if it's not working 20:43:06 dhellmann: had review/editing help from ttx, markmc, sdague (at least, sorry if i forgot someone) 20:43:26 sdague: except I suspect rechecking won't really help ? 20:43:43 sdague: i think the case being considered is when translations actually just don't work, yeah 20:44:04 doesn't seem like the type of test that would trigger rare issues 20:44:19 markmc: that makes sense if it's the translation import that's most likely to break operation due to errors 20:44:23 markmc: is that the case? 20:44:32 anyway, just wanted to attract your attention to the fact that they need some guidance there 20:44:44 or is it the case that people could break things by changing some log format translation function call or something? 20:44:48 jeblair, I think so - struggling to concoct another case 20:45:00 ttx: sure, sorry, with all the gate stuff my queue of paying attention is sort of at overflow 20:45:00 (i'm genuinely asking -- i'm not that familiar with the mechanisms here) 20:45:07 jeblair: it's possible someone could remove arguments to a message, and the existing translations would then expect a value that isn't present 20:45:22 dhellmann: and that would only be detected if you set a non-c locale? 20:45:39 jeblair: yes, because the default message would be changed in place 20:45:44 jeblair, it's usually a format string that the translator has messed up such that we get format errors at runtime 20:45:49 markmc: there were unusable translatons shipped in releases in the past... would be good to look back at those cases ad see what made tem fail 20:45:49 yeh, this is the thing where I'm sort of surprised the i18n team doesn't have an answer, because they know what's supposed to work in a real cloud. I'd kind of expect them to propose what they expect to work in such a situation. 20:46:05 jeblair, there is some automated checking of that with msgfmt -c, but it's not perfect AFAIR 20:46:06 and then we go from there 20:46:12 OTOH, the Message class could be made to trap those formatting errors and return the original message 20:46:34 dhellmann, possible, yeah 20:46:34 dhellmann: that seems more elegant 20:46:37 * dhellmann checks if that's already the case 20:46:59 anyway, I think we can provide guidance on that review 20:47:10 no need to solve it now 20:47:17 I don't see it doing anything that smart. I'll open a bug for that. 20:47:18 if we want more, due to the combinatorics inovlved, we may want to use static analysis 20:47:19 ttx: ack 20:47:29 * Modify Images mission to fit Artifact Repository (https://review.openstack.org/98002) 20:47:56 I think we have a winner there 20:48:21 the title change is still blocked on marketing feedback 20:48:26 due next week. 20:48:46 so approving the mission change would effectively unblock glance 20:48:55 changing the mission now and title later seems like a good path forward 20:49:00 +1 20:49:04 we can tweak the program name later when everyone is comfortable with it 20:49:17 cool, will approve when it gets 7 YES 20:49:22 if it hasn't already 20:49:23 also, if it completely fails to happen, we don't have egg on our faces. :) 20:49:30 ha, fair point 20:49:35 #topic Housekeeping changes (programs.yaml) 20:49:43 Those changes will all be approved unless someone complains: 20:49:48 * Adding Horizon mission statement (https://review.openstack.org/102050) 20:49:55 * Rename security-guide to security-doc (https://review.openstack.org/104295) 20:50:00 * Add docs-specs repo to Documentation program (https://review.openstack.org/104293) 20:50:05 * add keystonemiddleware to keystone projects (https://review.openstack.org/102305) 20:50:19 still a -1 from dhellmann on horizon mission statement 20:50:43 dhellmann: do you stand by it? Or is david-lyle reply acceptable to you ? 20:51:10 I'll stick with my -1 but won't object if someone wants to vote to overrule me. I think it's a mistake to mix implementation requirements into the mission text. 20:51:32 OK, I'll wendar ait for majority vote on that one then 20:51:36 err 20:51:41 I'll wait for majority vote 20:51:49 tabfail 20:52:17 #topic Open discussion 20:52:27 Looks like we can get the K vote started 20:52:33 awesome! 20:52:41 have the final list of candidates? 20:52:49 let me see which options passed the checks 20:52:59 unfortunately Kepler didn't make it 20:53:05 so I asked that we add Kilo 20:53:07 ?? 20:53:22 jeblair: Nvidia Kepler blame 20:53:25 poor kepler, we barely knew him 20:53:32 GPUs for cloud computing 20:53:35 * eglynn loses his bet on Kepler :( 20:53:53 just a sec 20:53:57 fetching list 20:54:19 Keryado, Kleber, Kourou, and Kyoto + Kilo 20:54:30 Kléber has a metro stop close by for photo ops. 20:54:34 We can still remove a name from that list if we want to 20:54:37 Kyoto and Kilo are separate options right? :) 20:54:51 kyoto is amusing from the standpoint of having chosen "havana" when we were in portland. :) 20:55:07 Kyoto is a bit disturbing since Place de Kyoto in Paris doesn't even show on Goog Maps 20:55:08 jeblair: was thinking the same thing 20:55:08 we almost have to pick kyoto 20:56:06 I almost want to remove Keryado, since it's really small in Brittany, and not really a fun exception 20:56:15 but then, we can keep them all 20:56:31 Kourou is fun as well, since it's in South America 20:56:39 and is in the space theme 20:56:53 kilo, less typing 20:57:01 we should have a 4 letter limit 20:57:06 Also, its time for openstack to go metric 20:57:06 i'd love a kilo of openstack right about now 20:57:08 anyway, I will start the public poll, probably thursday 20:57:14 And yes, I'll vote Kilo 20:57:25 takes the edge off 20:57:28 markmc: one letter limit! 20:57:30 It's been named K for so long anyway 20:57:40 it has to stand for Kilo 20:57:46 yup 20:57:56 yah, in my head it's already Kilo 20:58:02 Anything else, anyone 20:58:20 zaneb: unfortunately devs are not the only ones to vote, so expect Kyoto to win 20:58:27 lol 20:58:41 * zaneb thought Jeckyll was robbed 20:58:48 * markmcclain agrees 20:58:50 zaneb: agreed 20:59:17 ttx: any thoughts of having the TC sort out API feature discoverability. several projects are independently looking into it 20:59:29 ttx: maybe you should also send the announcement to openstack-dev? I usually miss it on the openstack list 20:59:29 there is a kyoto france? 20:59:49 clarkb: there is a place de Kyoto Paris (the icehouse exception) 21:00:16 jogo: which projects? 21:00:31 jogo: could be a good cross-project meeting topic / ML thread first 21:00:32 clarkb: http://fr.wikipedia.org/wiki/Place_de_Kyoto 21:00:45 ttx: nova (indirectly) and trove 21:00:52 ok, we are out of time 21:00:55 ttx: good point 21:00:56 jogo: I think that's got to be ML thread 21:00:59 jogo: neutron too 21:01:07 #endmeeting