20:02:04 #startmeeting tc 20:02:05 Meeting started Tue Apr 8 20:02:04 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:08 The meeting name has been set to 'tc' 20:02:14 Our agenda for today: 20:02:19 im fine w/ it too ttx 20:02:22 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:26 im here for the full hr 20:03:03 OK, let's do it in the agenda order then 20:03:09 #topic Integrated projects and new requirements: Gap analysis for Ceilometer 20:03:19 jd__: o/ 20:03:40 So the goal of this is... 20:04:06 since we formalized and increased the level of what's required for graduation over the last cycle 20:04:23 it's fair taht we look back at already-accepetd projects and make sure they comply 20:04:36 eglynn and I wrote something on https://etherpad.openstack.org/p/ceilometer-integrated-requirements 20:04:44 We did a number of those already (nova, neutron, cinder, keystone...) 20:04:45 which kind responds to most questions, we hope 20:04:50 now on to ceilometer 20:04:56 #link https://etherpad.openstack.org/p/ceilometer-integrated-requirements 20:05:44 o/ 20:06:16 jd__: sorry I can't help do some editing, hope that's ok 20:06:30 hehe sure 20:06:59 Missing mission statement is a significant gap, because Ceilometer is really a project/program that could use one :) 20:07:18 o/ 20:07:21 luckily there's a quick fix on that one 20:07:43 ttx: yep, I was hoping we'd crisp that scoping aspect up at summit in ATL 20:07:59 seems QA and Docs sections have the other big gaps? 20:08:24 yeh, I think the QA capture is about right. I'm definitely concerned on how exposed things are in the gate today as we have pretty minimal testing. 20:08:32 russellb: +1 on QA, again planned to be a major focus for Juno 20:08:35 yep 20:09:25 a related question, just because it's exposed in the gate, is performance with the sql driver. I feel like we're at an uncomfortable ground of it being in tree, but not working great 20:09:26 I think the contributor base is sane 20:10:13 I'd like to see monitoring section beefed up in the Ops Guide with ceilometer first-class citizen 20:10:13 sdague: yep, I think it's something more precise we didn't capture in that etherpad because we focused on the big picture, but it's one of our concern 20:10:18 sdague: is the sql driver the default back end? 20:10:25 any plans for juno to pitch in on the docs side? 20:10:28 sdague: yep, I wouldn't consider the sqla driver to be production-ready, yet the gate hinges on it 20:10:47 eglynn: what is the recommended back-end then? 20:10:56 and ideally that RDO quick start could go into the upstream docs 20:10:58 where do things stand with feature-completeness in the storage drivers? 20:11:14 devananda: mongo if you're asking my personal opinion 20:11:19 hmm 20:11:23 eglynn: right, and I think we mostly did that on the ML, so I don't think we have to rehash it here. 20:11:27 dhellmann: (modulo the potential licensing issues) 20:11:46 i’m definitely sad about mongo as the only viable option 20:11:49 so then I should point out the same concern I had for Marconi w.r.t. non-apache-compatible back ends and lackign support for an apache-compatible one 20:11:59 there has been discussion work on cassandra/hbase which seems promising 20:12:00 devananda: yeh, I think that's fair 20:12:01 yeah, all of that is nothing new 20:12:08 eglynn: is the sql driver feature-complete but non-performant? 20:12:12 #info Ceilometer gap: program mission statement 20:12:28 #info Ceilometer gap: Integration tests 20:12:35 devananda, we've had a long thread about that, if we want to re-hash let's schedule a TC discussion about it 20:12:42 #info Ceilometer gap: documentation 20:12:52 markmc: no need to rehash. I just wasn't aware of that issue w.r.t. ceilometer 20:12:53 dhellmann: yes its much closer to full parity ... the major outstanding feature gap has been closed in Icehouse 20:12:53 I think the concern was that sql backend was a requirement for graduation, but seems to not be keeping up 20:13:21 eglynn: ok, so closing that and then fixing the performance issues? I think some of the performance was hurt when the tables were normalized, but that's just a guess. 20:13:22 #info Identified concern: SQLA not recommended in production but still only backend tested in gate 20:13:27 markmc: i was only pointing it out since that seemed to be a preventatively-large gap for marconi's graduation 20:13:49 one of the post-graduation expectations we documented recently was integration with heat and horizon, if applicable. what integration exists there? 20:14:00 dhellmann, sdague: yes the sqla performance gap will be targeted for Juno 20:14:07 eglynn: great 20:14:30 russellb: integrated with both, metering dashboard in havana, ceilo alarms for heta autoscaling 20:14:37 thanks 20:14:46 s/heta/heat/ 20:14:59 is there any integration possibility with sahara (hadoop backend) being considered? 20:15:20 annegentle: not AFAIK 20:15:58 annegentle, sahara isn't installing managed db 20:15:58 what's the story relative to stacktach? at one point I thought that was largely merging into ceilometer, but it seems to have become it's own stackforge project 20:15:58 annegentle: there was some discussion in HK about using hadoop for generating roll-ups 20:16:08 jd__: not under consideration or unpossible? 20:16:09 annegentle: but came to naught for Icehouse 20:16:30 branen: not under consideration :) 20:16:33 eglynn: okay. I'm working through icehouse blueprints and saw hbase work so wondered 20:17:11 sdague: re. stacktach, the RAX folks contributed persisting of notification payloads and an events API in Icehouse 20:17:13 any other gap we missed ? 20:17:20 I've heard of some discussion amongst operators that the TC should require projects to be seen to scale to production use before graduating 20:17:26 with ceilometer used as an example 20:17:26 annegentle: there is habse storage driver already in existence 20:17:32 eglynn: there's also a summit session to revisit the merge, iirc? 20:17:36 how would you guys have felt if we had required this? 20:17:46 how would you have gone about making that happen? 20:17:48 annegentle: (and healthier than before as one of our new cores has taken it under her wing) 20:17:52 would it have helped you in the long run? 20:17:58 (perhaps off topic) 20:18:08 dhellmann: yes that would be good 20:18:35 markmc: it probaly helped focusing on some stuff than others 20:18:35 markmc: it would have helped definitely in my opinion 20:18:38 +would have 20:18:54 markmc: ... and testing at scale is something we really need to attack 20:19:04 how would it have worked in practice, though? 20:19:06 markmc: ... but counter-factual history is not my strong suit ;) 20:19:31 do you feel you would have been able to reach out to operators and have them test at scale? 20:19:31 markmc: what does scale to prpduction mean ? 20:19:38 OK, if we are done with the gap analysis, i'd like to give one week (and the new PTL being elected) to come up with a plan to address those gaps asap (ideally in Juno) 20:19:48 lifeless, right 20:19:49 (the scale to prod is off-topic) 20:20:11 markmc: ... I would like to have roped in some real operators to give us access to realistically sized gamma envs 20:20:13 and us discussing that plan 20:20:14 ok, sorry - was with a view to potential graduation requirements in the future 20:20:16 ttx: agreed, but a good atlanta topic 20:20:54 sdague: I want to make sure those topics are taken into consideration in design summit scheduling 20:21:01 so rough plan in one week 20:21:12 early enough to translate into key design summit sessions 20:21:21 where details will be fleshed out 20:21:32 gap covering should be Juno's priority 20:21:33 ttx: rough plan of the summit session needed to address the gaps identified above? 20:21:40 *sessions 20:22:03 eglynn: rough plan / set of blueprints you would implement in Juno to address those gaps 20:22:14 that will revolve mostly around tempest and SQLA perf 20:22:15 ttx: understood 20:22:22 imho 20:22:44 ttx: makes sense, +1 20:22:58 eglynn: jd__: and attend the cross-project docs session :) 20:23:01 #action Future ceilometer PTL to come up with rough gap covering Juno plan for next week meeting 20:23:15 jd__: i'll let you communicate to gordon 20:23:25 the threee of you should be able to come up with something 20:23:46 any other comment on that part ? A gap we would have missed ? 20:23:56 sure 20:23:57 ttx: yep, we can synch up with gordc tmrw 20:24:40 ttx: I think we covered it 20:24:44 ok then 20:24:49 #topic Bylaws subcommittee report: proposed changes to the OpenStack Bylaws 20:24:57 #link http://lists.openstack.org/pipermail/openstack-tc/2014-April/000609.html 20:25:04 EEvans, zehicle: o/ 20:25:09 o/ 20:25:35 The Bylaws subcommittee at teh Board of Directors has been working on propsoed changes to the bylwas that affect the sections about TC 20:25:40 Mark is scheduled to present, but he's having difficulty logging in. 20:25:57 the link above has links to bylaws diffs 20:26:10 there is a 15->18 diff and a 17->18 diff 20:26:24 15 being current state, 18 proposed state 20:26:44 17 being the initial proposed changes that markmc sent us a few weeks ago 20:27:06 it's more than a little confusing to follow 20:27:13 ttx: zehicle: EEvans: are there changes to other sections (that we're ignoring for now) -- is this diff parceled out just for the defcore changes? 20:27:21 github have a new prose diff thing, right? perhaps we should try that :) 20:27:32 EEvans, zehicle: I read it, the only thing I found confusing was the language in page 8 20:27:43 let me quote 20:27:48 these are all of the proposed changes. But it's an early view ... still under discussion 20:28:26 "After the OSP New Definition Date, the scope of the Core OpenStack Project which is an integrated release shall be determined as set forth in Section 4.13(c)(ii). " 20:28:30 EEvans: ok thanks 20:28:39 "the Core OpenStack Project which is an integrated release" sounds very confusing to me 20:29:03 the additions to 4.13 (page 9) are pretty confusing too 20:29:05 Core is a subset of the projects we commonly release in an integrated fashion 20:29:10 I don't see anything obviously wrong, but these documents are very long. 20:29:11 ttx: that sentence sounds like it is missing some words 20:29:23 should we rephrase this?? 20:29:36 ttx, I think these changes are redefining Core to mean Integrated 20:29:40 ttx, I *think( 20:29:51 EEvans, perhaps we should start by discussing what the goal is 20:29:54 EEvans: is that saying something about what portion of the overall project will be considered as core is going to be determined by section 4.....? 20:29:55 not clear to me any more 20:29:57 markmc: ah? 20:30:10 markmc: +1 20:30:19 EEvans: depends on what that sentence was trying to actually mean 20:30:41 markmc: I didn't read it that way at first, but I do see what you're saying 20:30:42 this: 20:30:44 "The Technical Committee shall propose a process or procedure to determine the scope of the Core OpenStack Project. The Board of Directors may propose modifications to such process or procedure but such modifications must be approved by the Technical Committee. After the Technical Committee has approved the final process or procedure for determining the scope of the Core OpenStack Project and the Board of Directors has approved suc 20:30:44 h process or procedure, the Board of Directors shall set the date on which such process or procedure becomes effective and the first such date shall be defined as the OSP New Definition Date. After the OSP New Definition Date, the Technical Committee may propose modifications to such process and procedure. The Board of Directors shall consider such modifications and may approve or disapprove them. If the Board of Directors approve 20:30:45 s such modifications, the modified process and procedure shall become the method for determining the scope of the Core OpenStack Project on the effective date set by the Board of Directors. The process or procedure shall be described in reasonable detail in the minutes of the Board of Directors which approved it. After such approval, the Secretary shall post such description to the Foundation’s website. " 20:30:50 (sorry) 20:31:01 sounds to me to be about the process for defining the contents of the integrated release 20:31:08 yeah, I had a question about that section: 20:31:08 does the addition of the word “core” to section 4.13(c)(ii) change anything about adding non-core projects for incubation, or is that covered by the fact that we’re supposed to develop the process for adding core projects (which would include incubation)? 20:31:12 Since Mark Radcliffe is leading this and is unable to log in, can we table this until the next meeting? 20:31:14 markmc: if Core = Integarted in that document, then we should just drop "Core" and just say "OpenStack project" 20:31:17 that it's a TC controlled thing, but the board has to approve the process 20:31:44 ttx: the word "core" was just added to draft 18, I think 20:31:44 If Core <= Integrated, then that sentence needs to be rewritten 20:31:52 ttx, I think that was what v17 did, but my concern was that gave the board more power over the contents of the integrated release than they have now 20:32:01 ttx, or v15, sorry 20:32:04 yes that is what it sounds like 20:32:15 yes, this is confusing 20:32:25 EEvans: that might work best, having Mark Radcliffe here to guide 20:32:28 I am also having trouble tracking version items 20:32:31 someone should write out what we want in english, and then we can translate it to legaleze 20:32:39 EEvans: I think Mark said he could not be there next week, though 20:32:45 is Mark Radcliffe the only one who can summarize the goal of these amendments? 20:32:49 EEvans: he could log in via a web chat http://webchat.freenode.net/ 20:32:55 my understanding of the key issue is that there are some process changes that have the TC represent the community' 20:33:20 zehicle: that's my understanding of the intent, but that's not how I read the words that were written 20:33:27 here he is 20:33:28 dhellmann, I agree withyou 20:33:33 MFR: welcome 20:33:34 so I think it's just a phrasing and language clarity issue 20:33:58 I'm willing to circle w/ EEvans and Mark Radliffe to get translation 20:34:03 I think that would be a good next step 20:34:26 My concern was the wording of "The Technical Committee shall propose a process or procedure to determine the scope of the Core OpenStack Project." in 4.13 c ii 20:34:40 zehicle: yes, we need to understand the goal. At this point the TC has full control on what it blesses and works on 20:34:42 This is Mark Radcliffe, counsel for OpenStack Foundation. The changes are meant to keep the relationship between Board and TC the same but give both more flexbility 20:34:46 due to proposal in progress with defcore 20:35:05 MFR: welcome! 20:35:08 so TC can include anything in 'the integrated release' 20:35:14 MFR, could you summarize the goal of the changes? 20:35:32 'Core' used to be the subset of those integrated projects that we want to place trademark rules on 20:35:47 Is the goal to mix the two concepts ? 20:35:49 MFR, not just the goal as it relates to the relationship between the board and TC 20:35:53 The goal of the changes is to implement the Defcore recommendation 20:36:28 MRF, I thought we were trying to get the process out of the bylaws and into the TC & Board management 20:36:44 MFR: I think we understand the goal, but the wording is causing some confusion 20:37:04 what is the Defcore recommendation? 20:37:04 The current system depends on specific modules being in the Core, we are proposing to allow the TC and Board to set up a process to do it rather than naming modules 20:37:36 so the bylaws won't have to change as we change that definition 20:37:39 MFR, zehicle: so "Core" and "integrated release" are still two separated concepts ? 20:37:40 (of the process or of core) 20:37:55 we were confused by ""After the OSP New Definition Date, the scope of the Core OpenStack Project which is an integrated release shall be determined as set forth in Section 4.13(c)(ii). "" 20:38:09 Yes core and integrated release are different 20:38:20 I'm no native sepaker but 'which is an integrated release" in that sentence looks misplaced 20:38:20 ok, that sentence ttx quoted conflates them 20:38:32 speaker* 20:38:33 ttx: agreed 20:38:38 perhaps we should not have the word "core" in the bylaws at all 20:38:51 I think "which" should be replaced with "that" there -- it's a common misuse of which 20:38:53 zehicle: well that would be even more confusing 20:39:20 ttx, not if we actually define things clearly 20:39:36 of course, with my rewording it makes 4.13(c)(ii) apply to the integrated release, when that section has core all over it 20:39:37 "the Technical Committee shall have the authority to determine the scope of the Core OpenStack Project subject to the procedures described below" 20:39:43 that's pretty weird too 20:39:49 but I think the word "core" can be excellent - if we define 20:39:54 zehicle: I agree, but just removing the word 'core' won't be enough to define things clearly 20:39:58 our thinking previously was the board was responsible for the definition of "the Core OpenStack Project" 20:40:11 why change the bylaws to make it under the TC authority? 20:40:20 markmc: right, that was my sense of it too, that it flipped 20:40:27 and the TC was responsible for the content of the intgerated openstack release 20:41:04 it's not clear in this that core is some subset of integrated 20:41:12 it only really makes much sense to me if we're redefining "Core OpenStack Project" to me "Integrated Release" 20:41:16 which apparently isn't the intent 20:41:18 markmc, the DefCore is moving towards a test/capability defined definition 20:41:20 yes, I read it that way too. Core is still a subset of integrated but now it's also defined by TC 20:41:46 is "integrated release" covered by section 4(b)? 20:42:00 dhellmann: integrated release doesn't appear in bylaws 20:42:00 sorry, 4.13(b) 20:42:08 zehicle, ... test/capability defined definition of "Core OpenStack Project", right ? 20:42:11 dhellmann: it's a community thing, not a foundation thing 20:42:19 zehicle, why would that definition be under the authority of the TC? 20:42:36 dhellmann: it's the stuff that our community works on and that the TC (the representation of those contributors) blasses 20:42:41 blesses 20:42:46 markmc, it's not according to the DefCore process 20:42:46 yes, but 4.13(b) says we have the "authority to determine the scope of the OpenStack Project" without qualification for core or not, so would that cover our ability to classify things as integrated or not? 20:42:50 the use of "the Core OpenStack Project" uses Core as a collection and Project as a collection. That's not the way we currently think/talk about core or projects. Are the definitions changing then? 20:42:58 so I think that there's something to work out 20:43:04 dhellmann: that would drag it into the bylwas 20:43:13 but Designated Sections are TC domain and that could also be covered by the language 20:43:14 ttx: because maybe the bylaws don't need to care about integrated? 20:43:15 dhellmann, integrated release is behind "The management of the technical matters relating to the OpenStack Project shall be managed by the Technical Committee" 20:43:34 dhellmann: they don't need to care about integrated projects, yes 20:43:36 dhellmann, that's an earlier version of 4.13(b) 20:43:43 The existing bylaws define Core and the additios and deletions are proposed by TC and decided by Board. The changes were meant to let TC and Board adopt other procedures such as testing 20:43:49 dhellmann, v17 turns it into "the scope of the Core OpenStack Project" 20:43:55 ok, so what I'm trying to say is that if other sections of the bylaws cover the integrated release, and the new 4.13(c) is only about core, does that change the way we read it? 20:44:01 MFR: ok 20:45:00 So the *intent* is to move the process for determining Core (in current bylaws, proposed by TC and approved by BoD), to an outside process proposed by the TC 20:45:14 so that gives us flexibility 20:45:42 Yes 20:45:45 ttx, yes. 20:45:51 IF that's the intent and we don't touch the ability for the TC to decide what goes in openstack releases (independent of "core" concept), then I'm good 20:45:57 ttx, my understanding was the the TC would proxy for community if the process needs to be changed 20:46:07 Yes 20:46:11 I just find some sentences (like the one I quoted) a bit confusing 20:46:35 I think the "which is an integrated release" should just be removed 20:46:53 I find this proposed role for the TC surprising 20:46:57 I think that key is that the bylaws would focus on the process not the result 20:47:06 i.e. to be the one that proposes any modifications to the Core definition process 20:47:13 markmc: would expect the process to be driven by the board, right? 20:47:22 russellb, as it is now, yes 20:47:25 markmc: arguably we did have that role in the original bylaws 20:47:26 right.. 20:47:26 markmc: I was also surprised 20:47:32 markmc, I believe it was the approach modications, not propose 20:47:44 had the role of proposing additions/removals 20:47:48 not defining the process used 20:47:54 IIUC 20:47:59 That is correct. We can remove "an integtrated release" if it is causing confuson 20:48:00 not approach, approve 20:48:06 russellb: the proposal of the process was not TC 20:48:09 markmc: the original bylaws said we were proposing projects and the BoD approved them. Now we are proposing the process to select them 20:48:26 ttx: if that's the goal, why isn't the TC driving defcore? 20:48:35 ttx: ohh. okay that's helpful. Except we're not proposing the process in reality 20:48:35 * russellb confused 20:48:35 Yes, you are proposing the process 20:49:04 MFR: my perception is defcore is the process proposal 20:49:15 yeah, defcore is a board subcommittee, isn't it? 20:49:19 so maybe this should be rephrased 20:49:28 dhellmann: yes 20:49:29 Defcore propsoes and the TC approves 20:49:33 proposes* 20:49:35 Defcore is a Board committee 20:49:49 at least that would match what happens 20:50:13 Defcore could become the process but we still need the bylaws change to give it that role 20:50:46 MRF, so the board owns the process and the TC is the watchdog? 20:50:47 MFR: the bylwas change could state that the BoD (or one of its subcommittee) proposes a process, and that the TC approves it. 20:50:59 rather than the other way around 20:51:06 because that's what's actually happening 20:51:28 yes, i think that would be fine 20:51:33 zehicle drives the process proposal, and we comment/approve it 20:51:42 I'm not sure we have an approval role even now 20:51:46 No, TC proposes the process and both TC and Board agree on it. The Board has the ultimate responsibility under DE law for these matters 20:51:48 russellb: do you not want the TC to set up the process? 20:52:01 dhellmann: that's not what has been happening the last year 20:52:16 russellb: sure, but we're talking about the future 20:52:23 MFR: or defcore proposes, TC validates and BoD approves. 20:52:33 I think that's what's happening ^ 20:52:53 what does "TC validates" mean 20:53:00 approves first ? 20:53:02 ttx: yes. defcore may or may not be made up of only board members though, it's a subcommittee 20:53:16 We could set it up that way if you want 20:53:20 ttx: ok, just trying to clarify ... could have also meant "provides input that may or may not be taken into account" 20:53:49 if we replaced "defined core" with "defined our trademark requirements" 20:53:51 MFR: these bylaws changes describe something other than what we perceive current reality to be, so we're trying to understand the difference 20:54:00 then I think it would be pretty clear it's much more a board thing than a TC thing 20:54:09 the TC can help if asked, maybe 20:54:19 but approval role ... doesn't really make sense to me 20:54:24 "technical validation" is what we've been doing on this so far 20:54:25 agree with that 20:54:50 shouting when it started not making sense with the reality on the ground 20:55:07 MFR: who wrote these bylaw changes? you, or several board members? 20:55:08 the question is... do we need to do more ? 20:55:15 ttx, anyone in the community is welcome to do that 20:55:37 I think the bylaws change were written in a way that didn't sound like the TC was robbed of its influence of core 20:55:53 but I don't think we actually care if we lose our influence on core 20:56:10 I'd be more worried with us gaining a responsibility which didn't make sense for us 20:56:13 since we specifically arranges "integrated release" separated from "core" to let the Board own "core" 20:56:15 (assuming it doesn't make sense for us) 20:56:22 arranged* 20:56:33 markmc: right that's my memory of the original goal as well 20:56:35 I liked the split we had, where we specified core code and the board specified core features. 20:56:46 yep, i liked the core vs integrated separation we did a long time ago. i think the intent was to separate ourselves from the core bit for the most part 20:56:56 I wrote the changes. We are trying to preserve the role of TC but make the process for deterimining Core more fliexbile because we are moving away from Core defined by modules 20:57:15 i think it's possible we don't want the responsibility maintained here :) 20:57:24 MFR: ok, thanks for clarifying 20:57:28 zehicle, EEvans, MFR: so if "core" is defined as a subset of the TC-defined "integrated release", then you can remove TC from determining "core" completely 20:57:44 i want full control over the integrated release, but just participate in an advisory/consulting role on the core part 20:57:53 ttx: +1 20:57:53 MFR: zehicle: are "modules" defined as our current idea of "programs"? 20:57:54 Only 3 min left, we need to cover a few more points quickly 20:58:11 ttx, fair point ... except would need to define "integrated release" in the bylaws :) 20:58:31 annegentle, the proposal I'd been working around was more about major functional areas 20:58:32 markmc: may be worthwhile to do that 20:58:42 russellb: ugh 20:58:52 markmc: "a list the TC gives out" ? 20:58:54 russellb, indeed, may well be 20:58:54 it's hard enough to change the graduation guidelines now :-) 20:58:59 ok, no time left 20:59:05 The intent is not to reduce the authority of the TC. Modules in Core were defined by name in the orignal bylaws 20:59:06 ttx, "here's what you can choose from" ? :) 20:59:09 also want to make sure everyone knows that Appendix 8 - Trademark Policy - is eliminated in v15 20:59:11 we'll circle back on emails and maybe have a follow-up at a next meeting 20:59:13 I'll take an action item to work w/ EEvans and MFR on a translation and clarify the issues raised 20:59:24 so to me I interpret that deletion as "there will be just one way to use the mark" 20:59:31 annegentle: I hadn't noticed that, does something replace it? 20:59:38 so that might be helpful to clarify for us as well 20:59:46 #topic Minor governance changes 21:00:06 * Resolution blessing designated sections guidelines (https://review.openstack.org/84712) 21:00:09 * Add neutron-specs to the Networking program. (https://review.openstack.org/84489) 21:00:10 no "built for OpenStack" ? 21:00:11 The trademark policy will exist but right now we have "locked it down" and we are discovering that we need more flexibility 21:00:12 * Add the Kite key distribution service to programs.yaml (https://review.openstack.org/84811) 21:00:16 * Add mission statement to Cinder (https://review.openstack.org/84528) 21:00:18 annegentle, we'll come back to that again - it was NOT my understanding except that we will have clearer commercial uses 21:00:28 Those 4 will all be approved if they reach 7 YES 21:00:30 zehicle: okay 21:00:31 cross project summit proposals due in a couple days. i'll follow up via email to organize a subset of the TC to put a proposed set of sessions together, and we'll bring it back to the full group for blessing 21:00:35 * Adds integrated release names to programs.yaml (https://review.openstack.org/81859) 21:00:49 same here, but may need a few more iterations 21:01:03 annegentle, there was an email from lauren to the marketing list about a consolidation of trademark programs 21:01:09 ok, time is up 21:01:11 annegentle, separate from defcore 21:01:15 ttx: on that one, what did you think about not adding integrated-release: until it happens? 21:01:27 markmc: okay to me the trademark use is the reason to define core? 21:01:36 markmc: but I might be conflating 21:01:40 #endmeeting