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