20:01:24 <ttx> #startmeeting tc
20:01:25 <openstack> Meeting started Tue Sep  1 20:01:24 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:28 <openstack> The meeting name has been set to 'tc'
20:01:33 <flaper87> o/
20:01:33 <ttx> Our agenda for today:
20:01:38 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:47 <ttx> #topic OpenStack programming languages resolution
20:01:54 <ttx> #link https://review.openstack.org/217710
20:01:55 <sdague> o/
20:02:03 <ttx> So this resolution is about writing down that new languages are OK, but the TC will consider them in a case-by-case basis
20:02:12 <ttx> Currently it's undefined -- some people consider this is not a factor in their decision, and some others (like me) make it part of their decision when considering new project teams
20:02:19 <flaper87> ttx: you may want to time-box this
20:02:21 <ttx> So I think this clarifies and sets expectations
20:02:27 <ttx> yep, timeboxed to 30min
20:02:27 <lifeless> ttx: o/
20:02:31 <ttx> Now there are more than one objection to this resolution, and I'd like to understand them
20:02:37 <ttx> sdague and lifeless say (I think) that this is a top-down edict preventing picking up the right tool for the job.
20:02:42 <cpallares> o/
20:02:45 <ttx> I don't think it does: it doesn't say "only Python", it actually says the contrary.
20:03:00 <ttx> It explicitly states that other programming languages are OK. It just recognizes that there is a cost associated with supporting them and therefore we need to have a discussion about them first.
20:03:12 <ttx> sdague, lifeless: or are you saying that there is no community cost in adding up languages ?
20:03:22 <russellb> intent sounds quite reasonable
20:03:24 <ttx> or that this cost is by principle offset in all cases by developer convenience, so there is no value in discussing it ?
20:03:35 <mordred> o/
20:03:41 <lifeless> ttx: I'm saying a few things I think
20:04:10 * flaper87 would also like to understand better lifeless's and sdague's concerns
20:04:28 <lifeless> ttx: in no particular order: the cost model here is really hard to get right. I don't think the prose in the proposal is right; and I don't have a fixed version to offer :(
20:04:49 <annegentle> case by case is difficult when you start to evaluate all the surrounding tooling
20:04:52 <ttx> I think it's the TC's job to ensure the long-term health of our community
20:05:07 <ttx> annegentle, zaneb or dtroyer kinda say the proposal addresses just a part of the culture problem, but ignores other parts of the problem (or is not precise enough)
20:05:16 <ttx> annegentle: I agree with you, but I think due to the nature of the game it's easier to pass small resolutions (and evolve them over time) than to agree on a text that would be final.
20:05:23 <annegentle> ttx: ok, that's faiir
20:05:25 <ttx> So I consider this an incremental improvement, a stake in the ground
20:05:26 <annegentle> fair even
20:05:37 <mordred> ttx: I agree with that - I think a step is a step forward, even if it's not the last step
20:05:38 * zaneb doesn't disagree
20:05:47 <lifeless> ttx: 2) we have actual feedback on languages from the operators - obtained at the last summit, I wrote it up for the list
20:05:52 <sdague> ttx: sure, and I think right now, the long term health of our community has been pretty negatively impacted by not having java devs feel welcome, and one of our most critical pieces of project infrastructure is in java (gerrit)
20:05:52 <ttx> Currently our community is in a grey area where most people assume that only Python is OK, and some people assume that anything is OK. This resolution is about clarifying that
20:05:59 <mordred> basically, the "tools are great, but do have an associated cost" is the important part to me
20:06:11 <lifeless> ttx:  -> if we're going to formalise technology choices, I think we want to at a minimum be pulling that dialogue in too
20:06:11 <dtroyer> mordred: ++
20:06:23 <annegentle> mordred: I'm there too. Esp. reading about vulnerability management
20:06:34 <annegentle> I want sustainability and long-term thinking.
20:06:34 <dtroyer> I think we should at least say that those costs need to be included when considering a proposal
20:06:37 <ttx> sdague: because we've been sidestepping that discussion
20:06:40 <mordred> dtroyer: ++
20:06:51 <lifeless> ttx: 3) thinking about 'the code /we create/ as all of openstack' is a mistake IMO: the code is transitive all the way down
20:07:02 <lifeless> ttx: and the proposal didn't have any aknowledgment of that
20:07:03 <sdague> lifeless: ++
20:07:23 <ttx> lifeless: I respectfully disagree. i think we need to consider the community cost, not just the end result
20:07:33 <flaper87> ttx: ++
20:07:33 <lifeless> ttx: the question about developer costs is not IMO 'what does it take for dev X to switch code bases', but 'what does it take for dev X to fix arbitrary bug Y that they care about'
20:07:39 <ttx> because without a community we won't have an end result
20:07:47 <jaypipes> lifeless: what do you mean by that? sorry, I'm not sure what you mean by "code is transtive all the way down"?
20:07:50 <sdague> because assuming the varnish layer is openstack, and the rest of it is imatereal, feels really weird.
20:07:59 <sdague> jaypipes: rabbit
20:08:07 <flaper87> community cost and technical cost are the 2 aspects that I'm more concerned about
20:08:08 <sdague> zookeeper, casandra,
20:08:09 <lifeless> jaypipes: rabbit, mysql, zk, kernel, ovs
20:08:14 <sdague> libvirt
20:08:20 <lifeless> bash, systemd
20:08:23 <mordred> I think those are worthwile things to talk about - but I think if we try to solve all of them now we'll get nowhere
20:08:26 <lifeless> we've had bugs in all of these
20:08:29 <mordred> and I don't thin kit's the question at hand
20:08:33 <flaper87> mordred: ++
20:08:49 <annegentle> ttx: is the goal of the resolution to help teams decide whether to apply for governance?
20:08:51 <ttx> sdague: so what ? Because our full stack is coded up in 12 different laguages doesn't mean we should support a community that codes up in 12 different languages *in OpenStack*
20:08:53 <lifeless> mordred: when we start asking about the costs to do something in the scope of the project
20:08:56 <mordred> I think the question ttx is trying to clarify is "if someone wants to submit a new openstack project that has some non-python elements in it, is that ok? if so, how much?"
20:08:59 <annegentle> ttx: or to describe what we have?
20:09:03 <flaper87> lifeless: we'll keep having them but there are also other communities taking care of those projects that we can collaborate with
20:09:03 <ttx> mordred: yes.
20:09:12 <mordred> that is specifically about openstack developer process
20:09:13 <flaper87> mordred: exactly
20:09:20 <flaper87> exactly, again!
20:09:30 <mordred> I TOTALY think that lifeless question is valid and important and we need to dive in to it
20:09:34 <lifeless> flaper87: but these dependencies are things we opt into. We've already chosen to depend on e.g. erlang
20:09:43 <mordred> but I think we can address a tiny bit of the pie that we know is lurking
20:09:45 <annegentle> I'd still like to hear about SDKs - which should apply for governance based on this resolution? Any? Or Python only?
20:09:56 <ttx> So, there are exceptions obviously
20:09:57 <lifeless> The community cost being put up can be thought of in a few ways
20:10:06 <flaper87> lifeless: sure thing, that doesn't mean we all need to learn earlang. And I'm not trying to say it's not important rather than it's adifferent problem
20:10:09 <ttx> packaging recipes or SDK bindings, you have to use the local idiom to produce those.
20:10:15 <lifeless> flaper87: how is it different?
20:10:17 <ttx> Here we are talking programming languages, something you would code up a whole new service in.
20:10:22 <ttx> All our services happen to be written in Python today. We do web front-end coding in JS, and devstack is in bash. Period.
20:10:30 <lifeless> flaper87: every developer possibly needs to know erlang to fix bugs in openstack
20:10:50 <dhellmann> lifeless: that seems extreme
20:10:52 <ttx> lifeless: I... don't think we do
20:10:53 <flaper87> lifeless: I'm failing to see why but it's probably me
20:10:58 <lifeless> ttx: we have a raft of DSL's that are plenty complex themselves. Are you excluding those ?
20:10:59 <flaper87> lifeless: we don't develop rabbit
20:10:59 <markmcclain> lifeless: not certain I agree with everyone needs to know erlang
20:11:00 <zaneb> lifeless: the implication of what you're saying is that language choice should be a free-for-all and we don't even need to discuss it. I don't think that's what you want, but not discussing it is the only thing that the resolution proposed really rules out
20:11:01 <ttx> flaper87: not just you
20:11:05 <annegentle> ttx: services. right. other projects have been added that are Ruby, right? (Chef puppet)
20:11:08 <flaper87> ttx: glad to hear
20:11:09 <dtroyer> flaper87: it isn't you…if rabbit was 'one of us' I would agree
20:11:13 <sdague> yeh, so my concern is as follows: we decide we're the python cloud, docker is the go cloud, and mesos is the java cloud.
20:11:21 <dhellmann> lifeless: if you take that all the way, it means we need to understand VDSL or whatever they use for chip design these days, and I don't think that's true either
20:11:24 <ttx> annegentle: that's just a downstream packaging format
20:11:36 <lifeless> dhellmann: its a tad harder to switch out the hardware vendors :)
20:11:38 <ttx> we have no service coded up in Ruby
20:11:44 <ttx> or Erlang for the matter
20:11:53 <mordred> sdague: ya. I don't want to be the python cloud. I want to be the excellent open source cloud
20:12:00 <annegentle> ttx: ok, so your resolution is for service proposals only? Why differentiate?
20:12:00 <flaper87> sdague: I'd put it: "we're mostly python but we're cool with a diverse technology base. We just need to know how much and have a good plan to welcome them"
20:12:12 <ttx> annegentle: downstream and updtream
20:12:12 <sdague> flaper87: that's all well and good, it sets a tone
20:12:32 <ttx> one is packaging the other
20:13:00 <annegentle> I made a list of all the shared resources services get... it's over 20 resources. So do we have separate shared resources for services and "downstream?"
20:13:02 <mordred> yeah "in what language(s) do we write the code we collaborate on that we may ship as openstack"
20:13:04 <lifeless> markmcclain: so they clearly don't all know erlang. But when there is a bug in rabbit that affects us, do we code around it in Python, or do we fix the root cause
20:13:10 <ttx> basically, if you write apckages, they use a packaging DSL, which happens to overlap bash, or Ruby.
20:13:10 <crinkle> parts of the puppet modules are written in ruby
20:13:13 <jaypipes> sdague: mesos is C++, but ok :)
20:13:23 <lifeless> markmcclain: If we're talking community, and open source and so on...
20:13:34 * flaper87 will rewrite messos in rustlang
20:13:38 <mordred> flaper87: ++
20:13:42 <sdague> jaypipes: ok, my bad :)
20:13:43 <flaper87> mesos, even
20:13:51 <jaypipes> sdague: I got your point, no worries :)
20:14:03 <ttx> anyway, please consider that of the 3 languages used in current services, only 2 are fully supported by infra. JS is still in progress
20:14:04 <sdague> so, here is a concrete thing that has happened
20:14:38 <ttx> so the cost is not hypothetical, we are already struggling
20:14:58 <jeblair> ttx: java, oddly enough, is actually relatively well supported
20:14:58 <sdague> one of our large visible community users had a bunch of openstack services written in java, because you can do that thing, and it fits in our architecture. All that sits behind their firewall because they believe if they ever came forward with it they'd be told to shove off.
20:15:14 <dhellmann> I would feel a lot better about expanding our language base if we had more people working in cross-project areas for the existing languages
20:15:15 <ttx> we are also struggling with cross-project issues. AllI'm asking is that we keep the cost in mind when we consider adding more complexity in the dev community
20:15:28 <ttx> not closing any door
20:15:30 <jeblair> sdague: it feels like clarifying our position as in ttx's resoultion would be worthwhile then.
20:15:40 <mordred> jeblair: ++
20:15:42 <flaper87> dhellmann: right, and I'd feel a lot better if I were sure we can also have a good CI for those languages
20:15:47 <edleafe> jeblair: ++
20:15:54 <sdague> ok, and the current position seems "shove off"
20:15:55 <dhellmann> flaper87: right, that's one part of what I mean
20:15:55 <russellb> jeblair: ++
20:16:04 <lifeless> ttx: so why don't we have a statement that says the same thing about having a service at all ?
20:16:11 <mordred> and also clarifying, to dhellmann's point - "if you're going to show up with java, you have to know there is a very real non-zero cost to areas that are traditionally hard to staff/fund"
20:16:14 <flaper87> In summary, I don't think anyone is against new languages, I just think we should be cautious and this resolution tries to do that.
20:16:26 <ttx> sdague: current position is "nobody knows" because no resolution was swritten on it. You should see the proposed resolution as a step forward to not shove it off
20:16:27 <jaypipes> sdague: hmm.... not sure I agree with that. that particularly large community user isn't, IMHO, all that interested in "coming forward".
20:16:27 <zaneb> sdague: actually I'm pretty sure a lot of that stuff is on GitHub, it's just that nobody cares
20:16:32 <jeblair> mordred: yes
20:16:39 <flaper87> there are things we ought to guarantee before we welcome a project written in a "foreign language" (had to, sorry :P)
20:16:41 <lifeless> [6~
20:16:56 <flaper87> and those things we don't check on current projects because we already have them
20:17:12 <ttx> it's also OK if things are developed OUTSIDE OPENSTACK and we consume them
20:17:13 <sdague> jaypipes: maybe, I've heard different things. I think we've set a cultural non acceptance of it
20:17:14 <annegentle> I think that the common resources come with a cost.
20:17:24 <jroll> sdague: I'm curious if we tried to welcome those folks, and then asked them to do all the CI/packaging/etc work like we did with JS, how massively frustrated they would get and if they would end up finishing.
20:17:30 <lifeless> ttx: it is ok, but why did we do BigTent ?
20:17:36 <jroll> sdague: because it's a massive amount of work
20:17:41 <annegentle> and I think that looking into enabling and encouraging an ecosystem is a natural next step
20:17:50 <jaypipes> jroll: ++
20:17:50 <annegentle> we can't expand beyond our means
20:17:55 <sdague> jroll: I don't know
20:18:07 <ttx> lifeless: to allow more services to be developed in the OpenStack community with the OpenStack way
20:18:11 <mordred> jroll: well, I tihnk that's just the thing
20:18:14 <jroll> that's not to say we *shouldn't* welcome that; I think we should. just something to think about
20:18:15 <ttx> not to push every triangle in a square shape
20:18:17 <annegentle> jroll: yep, that's part of the issue, it's overwhelming.
20:18:23 <mordred> jroll: I'd like to be able to have a conversatoin with them about the work it'll take
20:18:33 <flaper87> ah and just to echo what I (and thierry) said in the review, I don't think being cautious is anti-big-tent
20:18:36 <mordred> jroll: so that they can be involved in making the judgement about whether it's too much
20:18:42 <mordred> RATHER than having them just think I hate them
20:18:42 <annegentle> mordred: but, what is the motivation? Growth? Power? (I'm really wondering)
20:18:43 <lifeless> ttx: so, I don't understand why e.g. Java wouldn't be OpenStack way
20:18:46 <mordred> which is not the case
20:19:17 <jroll> overwhelming is an understatement, I think. I guess it depends on number of people hacking on it :)
20:19:17 <ttx> lifeless: I don't say it is, I don't say it's not. I just say we need to consider it
20:19:20 <lifeless> ttx: another point is that languages creating silos
20:19:20 <ttx> and discuss it
20:19:25 <lifeless> every service is a silo
20:19:26 <mordred> annegentle: the motivation for them to be included? or for wanting them in?
20:19:29 <annegentle> Expansion can happen in a more layered manner.
20:19:30 <jroll> mordred: +1, like I said, we should totally be inviting
20:19:35 <lifeless> every new split out review team is a silo
20:19:36 <ttx> lifeless: not everyone is a language polyglot like you
20:19:45 <dtroyer> lifeless: big tent is creating silos already
20:19:47 <annegentle> mordred: I want them in, but I think that boundaries and expectations setting are also useful devices for community inclusion.
20:19:50 <lifeless> ttx: its not about that - I'm not disputing that there is a silo effect from language
20:19:50 <ttx> lifeless: yes, and taht's why we should not add insult to injury
20:19:53 <mordred> annegentle: TOTALLY
20:20:00 <zaneb> lifeless: because you can't use Oslo. you can't use keystone middleware. you can't use the packaging/requirements system that you're creating atm. So you're reinventing all of that. How does OpenStack benefit by doing that stuff again?
20:20:07 <ttx> and create even more silos than we already have
20:20:13 <lifeless> ttx: I'm saying that we *explicitly* set up a structure - years ago now - with separate teams -> conways law -> silos
20:20:20 <edleafe> zaneb: good points
20:20:26 <flaper87> zaneb: ++
20:20:34 <jroll> zaneb: indeed.
20:20:42 <mordred> zaneb: ++
20:20:43 <lifeless> zaneb: those are good engineering points
20:20:51 <zaneb> lifeless: or, more to the point, how can you say we should accept that without even talking about the cost/benefit tradeoff
20:20:53 <lifeless> zaneb: and I have no problem with that being called out
20:20:55 <flaper87> zaneb: exactly the things I'd like to see clarified as part of the "welcoming other languages"
20:21:03 <jroll> with the big tent, openstack is really just becoming an umbrella of infrastructure and community, more than a group of projects
20:21:05 <annegentle> so, if we offer certain shared resources for <well-defined-projects> those are an ecosystem
20:21:18 <flaper87> we don't check those things with python projects because we know they are there
20:21:19 <lifeless> zaneb: I haven't rejected a cost benefit model - I've said its very very hard to get it right
20:21:21 <annegentle> and then we enable additional expansions in meaningful ways
20:21:34 <ttx> lifeless: a cost benefit model is all I'm proposing here
20:21:36 <annegentle> ways that people would actually _want_ and not shy away from.
20:21:49 <jroll> and I'd love to grow that umbrella, but it's a ton of work to get to the same point. we spent 5 years getting to this point with python and infra/CI/packaging is still hard.
20:22:01 <flaper87> jroll: yup
20:22:07 <mordred> jroll: yah
20:22:08 <zaneb> lifeless: yeah, all ttx's resolution says is that the TC will look into it and decide case-by-case
20:22:22 <lifeless> jroll: OTOH the designs and patterns are well established, so its not the same exploration-as-we-go for anyone following
20:22:29 <ttx> rather than "nobody knows if it's even ok to suggest a language"
20:22:30 <dims> ttx: flaper87: so we need a checklist of things these new projects need to sign up for? (infra/CI/packaging)
20:22:32 <sdague> so, the current model also makes this assumption that instead of fixing key complexity issues at a protocol model, like in keystone, we just "fix it in middleware" and put it in everyone's paste pipelines
20:22:35 <jroll> lifeless: I'd like to think that, but look at the JS work
20:22:38 <jaypipes> jroll: yes, and deliberately so. and it was deliberately called out in big tent discussions that teams joining OpenStack would be responsible for contributing to cross-project teams like docs, infra, etc. and that those teams wouldn't be "doing the work for you".
20:22:48 <flaper87> dims: I guess we'll have to have it for everyone
20:22:49 <ttx> dims: the trick is, they don't sign up for anything
20:22:52 <annegentle> jaypipes: right
20:22:58 <sdague> which actually does make openstack a python only cloud
20:23:02 <ttx> or they say they do and then they don't
20:23:20 <lifeless> so if the proposal stopped at 'costs of supporting it.'
20:23:26 <lifeless> I'd be +0
20:23:33 <lifeless> like- I think there's a bunch of tuning on the cost model
20:23:38 <flaper87> sdague: whether we can fix that or not is not under discussion. The thing is, we *have* that problem now
20:23:44 <flaper87> and that problem affects new projects
20:24:14 <lifeless> also the editorialism about silos I worry about
20:24:26 <ttx> lifeless: ok, we are making progress :)
20:24:30 <annegentle> sdague: the services, yes, but does that matter to consumers?
20:24:31 <lifeless> because it just seems odd given our deliberate 'please silo everything' team design
20:24:37 <lifeless> like
20:24:46 <lifeless> if we *were one team* with sub-specialities
20:24:56 <lifeless> e.g. review access applies everywhere
20:24:59 <sdague> annegentle: that assumes the only people that ever will have a good idea to go in the "open cloud" will do in python
20:25:01 <ttx> lifeless: you disagree with the idea of "refraining from adding a language purely for convenience" when it doesn't bring anythign technically to the table
20:25:07 <annegentle> lifeless: you're onto something there... I was wanting to make counts of subteam members. I mean, it's impossible to collaborate with 100 people so we tend to collaborate in teams of less than 10 I think.
20:25:24 <annegentle> (and yes, my observation has nothing to do with languages but about ecosystems)
20:25:35 <lifeless> annegentle: yah, its my 'conways law is our enemy today' drum. I beat it at least once a cycle :)
20:26:04 <jeblair> ttx: a technical issue -- can a regular motion (passed by a majority) place a requirement that some future motion have a 2/3 majority?  or does such a motion need to be a change to the charter?  or does it need to require that it recieves 2/3 itself?
20:26:09 <lifeless> ttx: I disagree with what I feel are pre-judged conclusions in the proposal
20:26:20 <jaypipes> I think I'd be OK with saying something like "if your project uses some non-Python language for a particular reason, you need to first add support to the infrastructure, build, and docs systems for that language before the TC will consider your project to be OpenStack"
20:26:29 <lifeless> jaypipes: yes
20:26:33 <lifeless> jaypipes: +1
20:26:34 <flaper87> Can we agree that this spec needs to be reworded in some areas a bit but it's a good step forward?
20:26:39 <sdague> jaypipes: yes, I'm completely on board with that
20:26:43 <mordred> jaypipes: ++
20:26:44 <jroll> jaypipes: ++
20:26:45 <lifeless> *that* is objective, welcoming
20:26:48 <ttx> jeblair: yes, you may be right. We could come back to majority vote
20:26:49 <jgriffith> jaypipes: +1
20:26:51 <jroll> seems reasonable to me
20:27:00 * mordred hands jaypipes a unicorn
20:27:04 <dims> "you need to first add support to the" -> "we will work with you to add support"
20:27:11 <edleafe> jaypipes: ++
20:27:12 <annegentle> jaypipes: agreed. so conversely it's also okay for a project to _not_ join OpenStack on purpose?
20:27:12 * flaper87 hands jaypipes a unicorn FAMILY
20:27:15 <ttx> jeblair: I kind of wanted something that the next TC wouldn't easily reverse.. i.e. an added language should not be suddenly "removed"
20:27:16 <jaypipes> that puts the onus back on the submitter, where it belongs (as intended by the big tent discussions)
20:27:17 <sdague> and I think that's the kind of resolution I'd be fine with. "Here is table stakes to bringing in new language"
20:27:18 <markmcclain> jaypipes: ++
20:27:22 <ttx> I guess there are other mechanisms to do that
20:27:23 <jroll> dims: +1, I like that
20:27:25 <lifeless> annegentle: I think thats a given :)
20:27:26 <sdague> jaypipes: ++
20:27:34 <jaypipes> annegentle: yes, absolutely.
20:27:44 <jroll> dims: and I think that's been proven with the JS work, as well, infra has put a ton of help into that
20:27:49 <lifeless> ttx: the point of the next tc is to be allowed to do that :)
20:27:51 <dims> jroll: cool!
20:28:13 <ttx> lifeless: but yeah, the 2/3 doesn't really help either way
20:28:23 <fungi> from an infrastructure support perspective i do think that arbitrarily accepting projects with the expectation they'll do the legwork themselves is likely to lead to some unpleasant experiences. we can often take the 5-10 minutes needed to show new devs from another python project where to find sufficient information to figure out how to start getting things done. for a new language, we have just
20:28:25 <fungi> enough time to make them feel like we're telling them to shove off
20:28:38 <ttx> jaypipes: sounds like a good way to solve the cost/benefit analysis
20:28:49 <flaper87> fungi: for me it'd be more like: Get it done and we'll talk after that
20:28:56 <ttx> but also a good way to tell people to shove it
20:29:03 <sdague> fungi: well, put a warning in about the fact that this might take significant effort
20:29:04 <ttx> (to use sdague's analogy)
20:29:06 <lifeless> well
20:29:16 <lifeless> so there are really a couple of cost groups
20:29:21 <jaypipes> sdague: we welcome all. but we're not some cult that demands everyone join us. if you don't want to be in OpenStack, that's totally cool, too. (just don't call yourself OpenStack, of course!). But OpenStack is about "are you one of us?" Which is all about do you want to serve the good of the OpenStack community, do you want to play by the same rules, do you want to use the same cmomunication processes, etc. If you d
20:29:22 <jaypipes> on't, totally awesome. you're just not OpenStack.
20:29:24 <lifeless> there's the bootstrap-and-operational costs
20:29:25 <ttx> We are approaching timebox limit
20:29:27 <fungi> flaper87: yep, where "get it done" starts with telling them to try setting up a copy of all our infrastructure, and probably learning one or two new programming languages
20:29:27 <lifeless> infra
20:29:36 <lifeless> and there's the culture/community costs
20:29:38 <jaypipes> sdague: doh, sorry, the above was answer to annegentle
20:29:42 <ttx> I'll read the log again and try to come up with something better
20:29:47 <lifeless> The first is really clear and I think having a resolution around it is sane.
20:29:49 <zaneb> ttx: fwiw the 2/3 made me uncomfortable for reasons I'd struggle to explain
20:29:51 <lifeless> The second, nope.
20:30:02 <sdague> jaypipes: yeh, because I think I'm 100% on board with your new approach
20:30:25 <jeblair> lifeless: i do think there are culture/community costs; i do not think they are strictly prohibitive
20:30:29 <ttx> Thanks for the discussion, I think I understand the objections slightly better. I hope you understand the intent of this a bit better too. Please comment on the review.
20:30:31 <lifeless> jeblair: agreed
20:30:32 <sdague> zaneb: I would agree. It seems like a whole new bylaw bit that's being patched in at the same time as a content bit
20:30:47 <dhellmann> jaypipes: I'm inspired to propose that all existing projects must have active liaisons in the cross-project teams to stay "official"
20:30:48 <ttx> sdague: agreed
20:30:49 <annegentle> it reads awfully governance heavy
20:30:49 <jeblair> ttx: thank you :)
20:31:01 <dims> dhellmann: ++
20:31:02 <zaneb> ttx: like, consensus is good, but when you put a number on it it reads like a challenge to try to screw over the minority ;)
20:31:05 <annegentle> ttx: but I do get the small reviewable idea
20:31:06 <flaper87> dhellmann: ++
20:31:10 <ttx> sdague: as I told jeblair, was trying to make such decisions "more sticky" but it's not the right way to do it
20:31:17 <lifeless> jeblair: [I just don't think that we can put them up as clearly as we can the bootstap/operational ones, certainly not in a balanced way today]
20:31:32 <ttx> cpallares: around?
20:31:38 <sdague> yeh, because the reason things are sticky is because we agree on them, not for procedural tricks.
20:31:41 <cpallares> ttx: Yes
20:31:42 <Rockyg> dhellmann, ++!
20:31:42 <lifeless> ttx: better question: why is that (stickyiness) valuable
20:31:58 <jaypipes> dhellmann: +10
20:32:00 <ttx> ok, moving on. Feel free to comment on review or discuss it with me anytime
20:32:04 <ttx> #topic Comments on applicability of Django CoC to OpenStack (cpallares)
20:32:09 <ttx> #link https://www.djangoproject.com/conduct/
20:32:17 <ttx> So, we ALL read it I believe
20:32:21 <annegentle> twice!
20:32:25 <ttx> Personally I think it's sane for the community code of conduct.
20:32:34 <ttx> I like the idea of a clear committee to handle violations and clear reporting guidelines
20:32:39 <mordred> ++
20:32:44 <sdague> ++
20:32:47 <jgriffith> ++
20:32:50 <flaper87> ++
20:32:53 <ttx> One thing that is missing in the Django CoC is corporate bullying -- leveraging money or influence that big companies have to push someone in the community to do something they naturally wouldn't
20:33:05 <ttx> I guess it's tricky to include since it's no longer "an individual" but "several execs at a company" misbehaving.
20:33:08 <annegentle> I don't like the reporting by anonymous email.
20:33:25 <cpallares> annegentle: Why is that?
20:33:29 <Rockyg> ttx: not just execs, managers
20:33:39 <flaper87> annegentle: setting up a CoC team might help
20:33:45 <ttx> So, not sure how to address that -- I'm only mentioning it because we had such cases raised as CoC violations in the past
20:33:52 <flaper87> direct email addresses that should be included?
20:33:53 <annegentle> cpallares: if I really have a violation I will use a phone and a real person
20:34:13 <russellb> ttx: do you mean pressuring their own employees?  or employees of other companies?
20:34:19 <jeblair> also missing are "be collaborative", "when we are unsure, we ask for help", "step down considerately" and "respect the election process"
20:34:22 <annegentle> also safety of both the accused and victim
20:34:23 <russellb> just trying to understand the concern clearly
20:34:28 <ttx> russellb: other companies
20:34:28 <jgriffith> annegentle: would having a general email and published members of the team work?
20:34:28 <flaper87> cpallares: sometimes ppl don't want chats or things that can be copied around
20:34:32 <russellb> ttx: ack
20:34:32 * flaper87 shrugs
20:34:32 <dhellmann> annegentle: I think for the django community, the email is used for online stuff more than in-person stuff?
20:34:39 <annegentle> jgriffith: yeah that's pretty much what we have now
20:34:44 <markmcclain> ttx: sure it isn't both?
20:34:50 <annegentle> dhellmann: ah ok
20:34:54 <Rockyg> flaper87, ++
20:35:02 <dhellmann> annegentle: so that might apply to us on irc, for example, vs. at a summit
20:35:03 <flaper87> At conferences there's a team that you can talk to
20:35:07 <ttx> markmcclain: well, pressuring your own employees to do your bidding is called employment, I think.
20:35:09 <flaper87> and we should have the same
20:35:12 <jroll> annegentle: for conferences django uses https://2015.djangocon.us/code_of_conduct/
20:35:16 <jroll> which includes phones and such
20:35:19 <russellb> ttx: :)
20:35:22 <jgriffith> ttx: hehe +1
20:35:23 <cpallares> Yeah, the summit has its own code of conduct
20:35:24 <annegentle> jroll: ah, thanks
20:35:25 <dhellmann> annegentle: I do agree, I'd like to be speaking with a human in real time if I had to report something
20:35:30 <markmcclain> ttx: depending on context possibly
20:35:36 <jroll> totally +1 on live contacts for in-person things
20:35:39 <annegentle> I guess we'd need an audit trail
20:35:46 <sdague> annegentle: so what you are really looking for is an OpenStack ombudsman, right?
20:35:46 <markmcclain> ttx: but I also think that is an internal HR issue at that point
20:35:46 <jaypipes> jeblair: all excellent additions.
20:36:06 <russellb> right, i don't think the foundation / project has any business dealing with issues between employee vs employer
20:36:12 <ttx> markmcclain: sure, I understand your point, was just making a joke. The question of the different hats is slightly less obvious I think
20:36:16 <annegentle> basically the details in https://www.djangoproject.com/conduct/reporting/ are sufficient to me
20:36:31 <annegentle> addresses confidentiality concerns
20:36:36 <jgriffith> russellb: yeah, that's seems a bit... umm... well; let's move on ;)
20:36:52 <dhellmann> ttx, cpallares : is the proposal to replace our coc with this one, or to augment ours?
20:37:08 <cpallares> dhellmann: I would prefer to replace it.
20:37:09 <mordred> russellb: no - but I do think they have businss in dealing with issues between a human and a company that person does _not _ work for
20:37:15 <ttx> dhellmann: cpallares is working on the board committee setting to replace the current CoCs
20:37:22 <annegentle> russellb: it's difficult when the person isn't employed though.
20:37:23 <cpallares> dhellmann: and give it its own place within OpenStack
20:37:31 <russellb> mordred: agree
20:37:31 <annegentle> russellb: the Foundation is the only help we would have
20:37:41 * jgriffith is rather confused now
20:37:45 <dims> cpallares: have folks looked at the ASF one too? http://www.apache.org/foundation/policies/conduct.html
20:37:51 <dhellmann> cpallares: ok, jeblair pointed out several missing sections that we have now that would be missing if we replace it
20:38:02 <russellb> annegentle: totally agree
20:38:16 <flaper87> I think we should merge them, not do a 1:1 replacement
20:38:22 <flaper87> at least, that's how I read it
20:38:31 <ttx> flaper87: ack
20:38:33 * flaper87 didn't attend last week's meeting but read the logs
20:38:35 <cpallares> dhellmann: Good point
20:38:40 <jgriffith> my only suggestion about "merging" is to be careful you don't end up with a novel
20:38:58 <ttx> cpallares: I think the next step is to collect that feedback and come up with a practical proposal
20:39:02 <dhellmann> flaper87: yeah, I think I misunderstood what I was supposed to do, and I noticed that we're missing 2 sections from the django one (be welcoming, and be careful in the words you choose)
20:39:20 * jaypipes is all fine with these Django CoC points, except for the "Be friendly and patient" one. I can guarantee no such thing 100% of the time
20:39:21 <flaper87> jgriffith: yup, I trust cpallares on that!
20:39:28 <dhellmann> I do like the fact that they have a more detailed reporting guide to augment the actual policy
20:39:30 <annegentle> jaypipes: ha!
20:39:36 <jaypipes> annegentle: :P
20:39:44 <ttx> jaypipes: you've been improving on that.
20:39:45 <annegentle> I think the detailed processes are great and we should layer ours similarly
20:39:47 <mordred> jaypipes: right? on the other hand - even when you're neither - you usually are still _striving_ to be
20:39:47 <fungi> friendliness and patience are rather subjective concepts
20:39:50 <jaypipes> ttx: barely ;)
20:40:01 <mordred> jaypipes: so maybe "Strive to be friendly and patient"?
20:40:01 <ttx> We need to move on
20:40:09 <russellb> definitely a variety of interpretations of what "friendly" means around openstack (and everywhere)
20:40:12 <ttx> cpallares: any question you have ?
20:40:16 <jgriffith> jaypipes: are you telling me there's no room in all of Del Boca Vista!!!
20:40:21 * mordred friendlies russellb upside the head
20:40:25 <ttx> I suspect TC members can reach out to you directly if they have further feedback
20:40:29 <annegentle> cpallares: feel free to ask me for help on the layering
20:40:33 <dims> mordred: lol
20:40:35 <cpallares> annegentle: I will thanks
20:40:36 * flaper87 wants to be friendlied
20:40:44 <ttx> Alright, moving on, busy agenda
20:40:46 <annegentle> flaper87: oh dear
20:40:47 * mordred has a special llama waiting for flaper87
20:40:47 <ttx> #topic OpenStack Community App Catalog application to join the Big Tent
20:40:52 <russellb> flaper87: tmi
20:40:53 <ttx> #link https://review.openstack.org/217957
20:40:59 <ttx> I think this is an easy one, it's clearly a community project now
20:41:04 <flaper87> mordred: LOL
20:41:06 <ttx> and the deliverable (apps.openstack.org) is already an openstack official thing anyway
20:41:18 <ttx> My only question would be whether Chris will be able to continue working on it now that he moved to IBM, since this effort relies a lot on him
20:41:26 <ttx> I guess we can ask mordred the question
20:41:27 <jaypipes> jgriffith: :)
20:41:35 * docaedo waves too
20:41:37 <mordred> yes.
20:41:52 <ttx> cool, then it's just missing a couple +2s
20:42:01 <ttx> unless someone has further questions
20:42:10 * russellb added +1
20:42:12 <ttx> flapping rob
20:42:23 <russellb> has 9 now
20:42:30 <ttx> Alright will approve asap
20:42:36 <ttx> no question ?
20:42:44 * Rockyg wonders whether mordred answered the question of being willing to be asked or whether chris was available
20:43:14 <russellb> "yes"
20:43:20 <jeblair> :)
20:43:21 <ttx> #topic Introduce assert:follows-standard-deprecation tag
20:43:27 <ttx> #link https://review.openstack.org/207467
20:43:30 <sdague> ttx: so, I just added a comment there
20:43:42 <ttx> sdague: 207467?
20:43:42 <sdague> which projects do we think follow 2 cycle deprecation for config options ?
20:43:46 <sdague> yeh
20:43:53 <sdague> because, in my experience, it's 0 of them
20:44:02 <sdague> except some oslo libs
20:44:12 <dims> :)
20:44:22 <ttx> sdague: are you suggesting we say "minimum 1 cycle deprecation for config options" ?
20:44:28 * dhellmann high-fives dims
20:44:32 <mordred> Rockyg: :)
20:44:35 <sdague> I'm suggesting that's what's out there
20:44:37 <annegentle> sdague: I dont't think it was 2 cycle for options but for API resources
20:44:42 <sdague> and has been the norm for a while
20:44:42 <ttx> (original proposal was 1 cycle but everyone said it should be 2)
20:44:54 <sdague> annegentle: I asked the question in the review for clarification, and was told it applies to config options
20:44:58 <flaper87> fwiw, Zaqar does
20:45:02 <zaneb> ttx: I think for config options specifically, 1 is all we need
20:45:04 <annegentle> sdague: yeah
20:45:11 <ttx> sdague: I'm fine rewording it so that config options have a one-cycle
20:45:12 <zaneb> ttx: in general, 2
20:45:23 <ttx> if that works for everyone
20:45:36 <ttx> sdague: the goal is to match what's out there
20:45:38 * flaper87 is good with that
20:45:40 <dhellmann> would that apply to libs, too, or do we count them as special for some reason? because I thought 2 was the rule already.
20:45:40 <sdague> flaper87: really, all of them? You want me to go sifting git logs. Because I found it was hard enough to keep people in nova from doing straight deletes
20:45:44 <ttx> not to invent a top-down edict :)
20:45:56 <sdague> ttx: yeh, that's why I've been a pita on this review
20:45:56 <ttx> dhellmann: it's a minimum. Not a ==
20:46:06 <annegentle> sdague: ttx: I think it was about being able to first: put a note in the logs from the service, in one release, and then second: actually remove it
20:46:09 <annegentle> doesn't that take 2 cycles?
20:46:10 <sdague> because, I've seen a lot of what happens in a lot of projects
20:46:12 <ttx> sdague: not a pita, just late :P
20:46:20 <annegentle> the communication cycle then the removal cycle?
20:46:21 <gordc> sdague: just to clarify, if there's an option to deprecate something, is the option itself expected to be deprecated a cycle after the actual deprecated feature is removed?
20:46:22 <flaper87> sdague: I've a very bad memory but Zaqar is small enough that it makes it easier to have a better look on what's happening
20:46:24 <sdague> ttx: well, I asked the question pointedly last week
20:46:24 <annegentle> or am I just off?
20:46:42 <dhellmann> annegentle: that's how I count, too
20:46:52 <dims> annegentle: agree
20:47:00 <sdague> annegentle: so typically projects just get their deprecations in by L3, and delete early in M cycle
20:47:02 <dhellmann> maybe we aren't all starting from the same understanding?
20:47:03 <zaneb> annegentle: that's only deprecated for one release by my count
20:47:10 <ttx> thing marked deprecated during the L cycle, can't be removed before start of N cycle
20:47:19 <ttx> that's what currently is in the proposal
20:47:28 <annegentle> ttx: ok that's what I want and will vote yes to :)
20:47:30 <ttx> i.e. it's marked deprecated for 2 "releases"
20:47:41 <zaneb> supported->deprecated->removed would be 1 cycle
20:47:43 <ttx> before being removed on the third
20:47:45 <sdague> ttx: right, and what I'm saying is that it would be good to actually go survey some projects before writing this one down
20:47:51 <annegentle> zaneb: it's the "marked deprecated" part. It could be reversed if enough reaction happened.
20:48:08 <zaneb> supported->deprecated->deprecated->removed would be 2 cycles
20:48:12 <ttx> sdague: that's fair. Could you re -1 it and ask me to do my homework first?
20:48:30 <ttx> no point in hurrying this
20:48:36 <sdague> so I -1ed with the comment that I think this applies to 0 projects right now
20:48:42 <sdague> I can add more -1 details
20:49:04 <ttx> sdague: oh, I read it now. Should be enough
20:49:21 <dhellmann> if we're happy with 1 cycle, do we need to do more research?
20:49:43 <sdague> I do think encoding sanity and what we do is a good thing, I just don't want to have the TC declare a thing, and it not actually be a thing anyone is doing, and demonstrate a disconnect from the projects
20:49:47 <ttx> dhellmann: need to see if we need to differentiate between config options and "features"
20:49:58 <annegentle> sdague: yep yep
20:50:01 <zaneb> sdague: ++
20:50:10 <sdague> which means we are going to need a definition of "feature"
20:50:25 <sdague> which ... is going to be a thing
20:50:31 <ttx> The trick is, this was never written, and there was a lot of oral tradition around "how we deprecate things in the integrated release"
20:50:38 <sdague> yes, for sure
20:50:54 <ttx> anyway, moving on
20:50:59 <ttx> #topic Adds & apply guidelines for project and service names
20:51:05 <ttx> #link https://review.openstack.org/201160
20:51:22 <ttx> This one (definition) looks ready to me, still missing one or two approvals
20:51:39 <ttx> #link https://review.openstack.org/201670
20:51:40 <annegentle> getting ready! :)
20:51:46 <ttx> This one (application) will need a rebase
20:51:51 <annegentle> ok, got it
20:51:58 <ttx> probably safer to wait for the first one to be approved
20:52:06 <annegentle> ok
20:52:19 <ttx> ok, it has 7 votes now, I'll approve the first one asap
20:52:25 <lifeless> \o/
20:52:30 <flaper87> w000h000
20:52:41 <ttx> annegentle: nice persistent work on that Anne
20:52:47 <annegentle> whew
20:53:04 <ttx> #topic Workgroup reports
20:53:10 <ttx> * Project team guide
20:53:17 <ttx> Project team guide is now up at http://docs.openstack.org/project-team-guide/
20:53:20 <flaper87> YEAH!
20:53:25 <ttx> So we don't really need the workgroup anymore, we'll include incremental fixes now
20:53:27 <annegentle> yeah!
20:53:49 <ttx> * Comms
20:53:55 <ttx> annegentle, flaper87: o/
20:53:58 <annegentle> guess it's a week for a post!
20:54:01 <flaper87> o/
20:54:04 <flaper87> annegentle: ++
20:54:10 <annegentle> I volunteer flaper87 to write it :)
20:54:11 <ttx> It is. We have app catalog, project team guide
20:54:17 * flaper87 accepts
20:54:18 <flaper87> wait, what?
20:54:20 <flaper87> :P
20:54:28 <ttx> (today) + the slack from past weeks
20:54:32 <flaper87> I was going to raise my hand this week, really! :D
20:54:38 <annegentle> yeah!
20:54:39 <ttx> * Cross-project track at Mitaka summit
20:54:48 <annegentle> thanks flaper87 :) I'll edit with ya
20:54:48 <ttx> Who is interested in driving that ? I know thingee wants to participate, I can volunteer too...
20:54:57 <dhellmann> ttx; sign me up again
20:54:57 <ttx> Anyone else interested in crafting an awesome cross-project track for Tokyo ?
20:55:07 <sdague> sure, I'd like to help
20:55:22 <sdague> I would also suggest that we do this one a little more top down this year though
20:55:29 <mordred> I'd love to participate as well
20:55:30 <ttx> it means being available in October to finalize it
20:55:32 <flaper87> annegentle: please please
20:55:33 <dhellmann> I've already started some notes in https://etherpad.openstack.org/p/mitaka-cross-project-session-planning
20:55:33 <flaper87> :D
20:55:45 * flaper87 interested in help with the CP track
20:55:46 <sdague> and have TC folks declare what they think some of the top things we need to solve are
20:55:58 <ttx> #info ttx thingee dhellmann sdague mordred available for cross-project track workgroup
20:56:08 <ttx> #info +flaper87
20:56:17 <flaper87> ttx: :D
20:56:35 <lifeless> ooo
20:56:44 <ttx> #topic Open discussion
20:56:47 <lifeless> I had stuff I was going to inject, and now my brain has paged them all out. nuts
20:56:50 <Rockyg> uh, me too?  From the prodwg perspective?
20:57:06 <lifeless> ttx: I'm interested too
20:57:21 <ttx> #info +Rockyg lifeless
20:57:27 <dims> ttx: we should ask this question in next meeting too :)
20:57:29 <jeblair> fyi stackforge move scheduled for oct 17: http://lists.openstack.org/pipermail/openstack-dev/2015-August/073071.html
20:57:33 <ttx> I have a question about whether we should have a TC dinner in Tokyo, and if yes, who will sponsor it
20:57:40 <ttx> with mordred's move from HP to IBM I suspect the question is open
20:57:40 <dhellmann> jeblair: ++
20:57:44 <flaper87> jeblair: glad to know, thanks for the heads up
20:57:53 <flaper87> whic dhellmann summarized, elegantly, with a ++
20:57:55 <flaper87> :P
20:58:04 <ttx> mordred: did your dinner budget change jobs as well ?
20:58:15 <jeblair> wait, mordred didn't pay for those out of pocket?
20:58:17 <mordred> I have checked with folks at HP who are still interested in funding the dinner
20:58:17 * flaper87 rofl
20:58:22 <ttx> or should lifeless pick up the bill
20:58:30 <mordred> so, let's assume it'll still happen
20:58:40 <mordred> and logistics of how it gets planned will be sorted out
20:58:50 <ttx> it's fine to split the bill too. As long as I don't have to pay for anything, I'll support it
20:58:53 <fungi> sounds like mordred's dinner budget got a better offer to stay behind
20:58:56 <lifeless> ttx: LOL
20:58:57 <mordred> I've offered to continue doing the legwork to organize
20:59:02 * flaper87 is with ttx
20:59:04 <mordred> fungi: :)
20:59:04 <jeblair> yay!  i'm hungry!
20:59:18 <lifeless> mordred: sounds like we need to get another P-Card
20:59:27 <mordred> I'll follow up with folks asap on what we learn
20:59:52 <ttx> mordred: Japan has a lot of micro-restaurant (one table) that still have Michelin stars
21:00:18 <ttx> anyway, time is out
21:00:19 <fungi> plop a tablet at each table and teleconference the tc dinner
21:00:25 <mordred> fungi: hahahahaha
21:00:26 <ttx> #endmeeting