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