20:02:32 <ttx> #startmeeting tc
20:02:33 <openstack> Meeting started Tue Jan  8 20:02:32 2013 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:36 <openstack> The meeting name has been set to 'tc'
20:02:42 <ttx> Agenda for today @
20:02:46 <ttx> #link http://wiki.openstack.org/Governance/TechnicalCommittee
20:02:54 <ttx> #topic Motion: Distro & Python 2.6/3.x support policy
20:03:04 <ttx> Motion was proposed by mordred and discussed at:
20:03:09 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2012-December/004052.html
20:03:18 <heckj> o/
20:03:20 <ttx> The only clear comment we had is that the "endeavor" clause could also include SLES.
20:03:36 <ttx> mordred: should we amend the motion before voting ?
20:03:56 <ttx> or do you prefer we vote on the original form ?
20:04:10 <mordred> ttx: hrm. perhaps? what about "endeavor to not break latest stable releases of distros who show up and care about us?"
20:04:30 * mordred trying to think how to be inclusive and not prescriptive now
20:04:43 * ttx hands annegentle a RNG
20:04:55 <russellb> though it turns the policy into a bit more wide open, instead of specifically defined
20:05:09 <russellb> not that i'm necessarily opposed, just thinking out loud ...
20:05:24 <mordred> yeah. how about we vote as is, and if it causes problems, we can always come back and talk about it
20:05:32 <russellb> wfm
20:06:23 <ttx> yeah, it's more about "supporting the current state of distros" (with the help of some specific distros to define it) than "supporting specific distros"
20:06:43 <markmc> well, "current state" is latest Ubuntu/Fedora
20:06:49 <notmyname> what about the phrase "impossibly or unnaturally difficult"?
20:06:51 <markmc> the LTS/RHEL clause was about specific older distros
20:07:22 <ttx> "latest Ubuntu/Fedora" is just a way to say "current", and "LTS/RHEL" a way to define "ancient but still around"
20:07:24 <mordred> well, I think impossibly gets vague - I'd like to define some threshold for why we care about things that aren't current
20:08:00 <russellb> but that's what it says now?
20:08:08 <ttx> though "latest Fedora" gets older as the day pass :P
20:08:14 <mordred> :)
20:08:20 <danwent> yeah, "endeavor" and "unnaturally difficult" seem quite vauge, to the point where I'm having trouble imagining how this could be used to make a decision if two parties disagreed.
20:08:28 <markmc> doesn't "latest Ubuntu" too?
20:08:30 <markmc> confused
20:08:53 <ttx> markmc: well, Ubuntu is released a bit more... regularly :P
20:09:06 <markmc> ttx, oh, you mean the fedora schedule slips?
20:09:14 <ttx> yeah (just a release manager joke)
20:09:20 <russellb> har har har
20:09:23 * markmc hadn't been paying attention to the slips :)
20:09:25 <mordred> it's possible that ttx might have introduced a classic flame war
20:09:55 <mordred> ttx: emacs' release schedule is better than vi's!
20:10:01 <russellb> so, vote?
20:10:03 <ttx> danwent: how about: "do our best to support" ?
20:10:05 <markmc> ok, do we really need to vote on this as if it's a policy for conflict resolution?
20:10:07 <russellb> or are there specific changes needed?
20:10:22 <markmc> monty has stated well what the current consensus is IMHO
20:10:36 <markmc> but there's an element of "SLES is pretty close to the bar" too
20:10:50 <markmc> it's always going to evolve
20:10:59 <markmc> as more distros get more involved
20:11:26 <ttx> "endeavor" and "unnaturally difficult" are quite vague because we don't commit to support them, it's only a best effort thing ?
20:11:40 <ttx> I think kthe current wording is ok, personally
20:11:44 <danwent> ttx: i'm still stuck on how two disagreeing people would use that to make a decision.  what is a practical exampmle of when this policy would be applied?  for example, if someone wanted to use a python construct that was only compatible with 3.0?
20:11:46 <mordred> ttx: well, we don't commit to much of anything other than releasing every six months
20:11:48 <russellb> cautious support, with an out :)
20:11:53 <mordred> danwent: yes
20:12:07 <danwent> so i'm not sure what "do your best" tells me in this case.
20:12:09 <mordred> danwent: that's the particular case in point - "use 3.3 feature that isn't possible to backport to 2.6"
20:12:34 <mordred> which clearly won't work for current RHEL - so it should be clear that we should not do that
20:12:56 <markmc> danwent, it's more "we will do our best" IMHO
20:12:59 <danwent> mordred: yup, agree that its important to have a policy on that.  just trying to make sure its one that can be interpreted clearly by someone doing a code review.
20:13:06 <mordred> danwent: good point
20:13:07 <ttx> and if breaking them is the only way to do it, I guess that could be brought to the TC again
20:13:32 <russellb> hard to imagine that being the case, but who knows
20:13:55 <danwent> maybe something like avoid breaking compatibility if an alternate mechanism that doesn't break compatability is also available?
20:13:56 <ttx> mordred motion says "it's an issue to break them, so we should avoid it" -- doesn't say 'we won't break it after careful consideration'
20:14:38 <danwent> or that we shouldn't break, unless doing so is the only way to achieve a key priority of the project?
20:14:38 <ttx> I expect such cases to be brought back to the TC if it ever happened
20:14:54 <markmc> yeah, careful consideration involving the rest of the project (i.e. mailing list) the TC is probably what we want
20:14:59 <ttx> i.e. "you shalt not break them unless the TC agrees"
20:15:00 <mordred> ++
20:15:14 <danwent> ok, that seems like a pretty clear rule.
20:15:35 <ttx> "the TC" in that case being the appeals board if consensus could not be reached below
20:16:13 <notmyname> I think a good point was raised in the mailing list thread. what does distro support actually mean? that we won't add features that aren't available in the default packages the distro provides?
20:16:15 <ttx> mordred: maybe the wording could be adapted to reflect that
20:16:25 <mordred> notmyname: I don't think it means that
20:16:35 <notmyname> me either
20:16:39 <ttx> notmyname: we already do that, forcing them to package stuff they don't have yet
20:16:45 <notmyname> in reality, we're talking about python versions (and what distros ship with) and kernel versions
20:16:58 <mordred> notmyname: I think it means that we won't do things that would cause a situation where the distro could not backport something
20:17:02 <mordred> notmyname: yeah
20:17:17 <markmc> libvirt versions too probably
20:17:41 <notmyname> so for swift, I can tell a deployer, "go get the LTS release, upgrade the kernel, and go"
20:17:46 <mordred> I think canonical is even potentially willing to backport libvirt to their cloud archive ... markmc do you think redhat won't do that?
20:18:17 <mordred> notmyname: yeah. (or at worst, go get the LTS, add the cloud archive, upgrade the kernel and go)
20:18:19 <markmc> mordred, it gets rebased pretty regularly, but there's still a lag
20:18:45 <markmc> mordred, we wouldn't put a newer version of libvirt in RH OpenStack than the one that's in RHEL though, no
20:18:55 <markmc> mordred, just wait for the next RHEL update to rebase libvirt
20:18:56 <notmyname> markmc: with "upgrade the kernel" actually being optional
20:19:11 <mordred> markmc: hrm. ok. good to know
20:20:31 <ttx> mordred: how about s/will endeavor to not/won't (unless the TC grants an exception)/ to clarify language ?
20:21:30 <markmc> well, if it's a TC policy just "won't" will do
20:21:31 <mordred> ttx: I'm ok with that
20:21:37 <mordred> indeed
20:21:40 <markmc> we can always just change the policy if the need for an exception arises
20:21:56 <ttx> "won't" it is then
20:21:58 <mordred> yeah. what markmc said
20:22:13 <ttx> Ready to vote ? Or more discussion ?
20:22:34 <danwent> one thought
20:22:53 <danwent> adding the (unless…) says that it is OK and normal to grant exceptions.  removing implies otherwise.
20:23:04 <danwent> i'm assuming we want to imply otherwise, which is why we remove?
20:23:06 <russellb> so with this changed wording, does the motion have to be posted to the ML again, and vote next week?
20:23:22 <ttx> russellb: no
20:23:31 <russellb> ok
20:23:47 <ttx> the ML discussion is for input, fueling our decision
20:23:54 <russellb> can someone draft the full motion with changes before the vote then?  want to make sure i caught it all ...
20:23:59 <ttx> not to present the ultimate version of the text
20:24:06 <russellb> k
20:24:06 <ttx> (especially for a cosmetic clarification)
20:24:14 * heckj could really use a synopsis of the latest version of the motion
20:24:32 <ttx> same, with s/but will endeavor to/and will/
20:24:59 <mordred> https://etherpad.openstack.org/python-support-motion
20:25:15 <heckj> mordred: thanks
20:25:27 <ttx> anything else before we vote ?
20:26:00 <danwent> i still think "unnaturally difficult" is pretty vague, but am fine abstaining :)
20:26:31 <mordred> we can fix that perhaps... what about just "impossible"?
20:26:46 <gabrielhurley> "excessively difficult"? or "impossible" is good.
20:26:50 <danwent> yeah, i think that would be more clear.
20:26:55 <mordred> updated
20:27:01 <russellb> it's just software, almost anything is possible
20:27:09 <gabrielhurley> russellb: +1
20:27:14 <markmc> the devil is in the details
20:27:22 <mordred> russellb: so far it does not wash my dishes for me
20:27:24 <markmc> if e.g. we wanted to require a newer version of libvirt than is in RHEL
20:27:25 <ttx> ok, ready to start vote unless someone objects
20:27:25 <notmyname> is repackaging python3 as part of your deployment "impossible"? ;-)
20:27:28 <danwent> markmc: i agree, which is what worries me
20:27:29 <markmc> we'd have a discussion
20:27:42 <markmc> it wouldn't be about the definition of "unnaturally difficult"
20:27:56 <markmc> it would just be about the impact on the RH distro folks if we required it
20:28:18 <russellb> i could argue that it's possible, even if RHT doesn't ship newer libvirt :)
20:28:25 <ttx> #startvote Approve proposed motion with paragraph changed as in etherpad? yes, no, abstain
20:28:26 <openstack> Begin voting on: Approve proposed motion with paragraph changed as in etherpad? Valid vote options are yes, no, abstain.
20:28:27 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:28:28 <danwent> i don't really have a stake here, so if the people that do think the wording is sufficient, i'm ok with it.
20:28:28 * russellb turns off -fpedantic
20:28:39 <markmc> #vote yes
20:28:39 <mordred> this is a good point ... we aren't lawyers up in here :)
20:28:40 <notmyname> I'd s/run/deploy/
20:29:00 <mordred> #vote yes
20:29:08 <russellb> #vote yes
20:29:09 <notmyname> #vote yes
20:29:12 <ttx> #vote yes
20:29:14 <bcwaldon> #vote yes
20:29:22 <danwent> mordred: sometimes i think code reveiewers are worse than lawyers
20:29:26 <vishy> #vote yes
20:29:26 <jgriffith> #vote yes
20:29:31 <danwent> #vote abstain
20:29:33 <ttx> Ending vote in 30 seconds
20:29:34 <mordred> danwent: ++
20:29:41 <annegentle-itsme> #vote abstain
20:30:09 <gabrielhurley> #vote yes
20:30:12 <ttx> #endvote
20:30:13 <openstack> Voted on "Approve proposed motion with paragraph changed as in etherpad?" Results are
20:30:14 <openstack> yes (9): markmc, bcwaldon, ttx, notmyname, vishy, russellb, jgriffith, mordred, gabrielhurley
20:30:15 <openstack> abstain (2): annegentle-itsme, danwent
20:30:36 <ttx> #agreed Motion accepted with paragraph rewrite
20:30:51 <ttx> now to go change that volatile etherpad
20:30:59 <ttx> #topic Update on the "Future of Incubation / core" joint committee
20:31:02 <notmyname> and paste it here for the logs
20:31:17 <markmc> ok, so we had another meeting before the break
20:31:17 <mordred> #agreed "OpenStack will target its development efforts to latest Ubuntu/Fedora,
20:31:19 <mordred> but will not introduce any changes that would make it
20:31:21 <mordred> impossible to run on the latest Ubuntu LTS or latest RHEL."
20:31:23 <mordred> gah
20:31:30 <ttx> #info OpenStack will target its development efforts to latest Ubuntu/Fedora, but will not introduce any changes that would make it impossible to run on the latest Ubuntu LTS or latest RHEL.
20:31:39 <mordred> thanks. that worked better
20:31:39 <ttx> So we had a meeting on December 20, slow progress as always
20:31:44 <ttx> markmc: quick update ?
20:31:51 <markmc> first we talked about "who are our users", in the context of what we're trying to achieve with "Core status"
20:32:12 <markmc> and agreed that it was about users of OpenStack clouds, rather than deployers
20:32:21 <markmc> i.e. the "core" status is about controlling their experience of the OpenStack brand
20:32:28 <markmc> (IMHO, this is all board territory)
20:32:52 <markmc> we talked about "the destination of Incubation" and agreed it is just "included in the co-ordinated release"
20:33:07 <markmc> i.e. you graduate from Incubation means you're included in the release
20:33:14 <markmc> but not necessarily in Core
20:33:29 <markmc> we came up with the working term "Integrated" to convey the distinction with "Core"
20:33:36 * markmc consults https://etherpad.openstack.org/IncUp
20:33:47 <mordred> I agree with the above as reported so far
20:33:56 <markmc> and we had a bunch more trademark/core related discussions
20:34:00 <mordred> (both in substance, and that it is being reported accurately)
20:34:22 <markmc> so not a whole lot in the TC territory, apart from "graduated from incubation" means "integrated in the release"
20:34:37 <ttx> markmc: I think now we need to work on better separating what's TC territory and what's board territory
20:34:56 <mordred> really? hrm - I thought that was really clear actually
20:35:12 <markmc> well, I thought there was good consensus that the TC decides what is "Integrated" and the board decides what is "Core"
20:35:21 <ttx> mordred: good then. I sometimes felt like everything was controoled by both entities
20:35:24 <mordred> what I took away was that the idea that incubation and integrated release were all technical matters...
20:35:29 <mordred> yeah - what markmc said
20:35:40 <ttx> ok then, all good
20:35:46 <mordred> because integrated is about technical things, and core is about brand things
20:36:00 <markmc> the TC can prevent a project from becoming Core by not allowing it to be Integrated
20:36:06 <ttx> mordred: that's obvious to me, just wondered if it was clear to the other directors
20:36:09 <markmc> but apart from that, separate responsibilities
20:36:13 <russellb> thanks for putting your time into this stuff, guys, and appreciate the update
20:36:16 <mordred> there was an interesting questoin that alan clark asked:
20:36:41 <mordred> which was "are there specific quality metrics used by the TC to determine suitability for inclusion, such as defect counts, etc"
20:37:07 <ttx> yes, we need to do a better job at defining what we require
20:37:25 <mordred> yeah. one of those times where a question made me think for a bit
20:37:29 <ttx> I tried to organize the discussion around key questions, like technical qualities etc.
20:37:38 <ttx> but some metrics couldn't hurt
20:37:40 <markmc> #link https://etherpad.openstack.org/IncUp
20:37:43 <markmc> #link http://wiki.openstack.org/Governance/Foundation/IncubationUpdate2013
20:37:58 <markmc> #info the TC decides what is "Integrated" and the board decides what is "Core"
20:38:07 <ttx> the other interesting question was "can an integrated project call itself "OpenStack X" ?"
20:38:09 <creiht> if you had the right gates you could automate the incubation process through Jenkins >:)
20:38:29 <ttx> but I guess that's for next week's episode
20:38:38 <mordred> creiht: ++
20:38:39 <ttx> questions ?
20:39:02 <ttx> next meeting on Thursday, open to anyone interested and having an hour to kill
20:39:11 <ttx> (invites not sent yet)
20:39:17 <mordred> creiht: we could make a TC group and do votes on motions by gerrit code review ...
20:39:45 <russellb> gerrit all the things?
20:39:51 <ttx> ok, no questions, then next topic...
20:39:57 <heckj> markmc: thanks, good overview
20:40:07 <ttx> #topic Discussion: Evolution of the TC membership to support potential growth
20:40:20 <ttx> I would like to kick off the discussion on how to best support further growth of the project while keeping the TC at reasonable size and reasonably representative
20:40:30 <ttx> Currently we do "all PTLs for core projects + 5 directly-elected", for a total of 13 members.
20:40:40 <ttx> This becomes a bit of a problem if we add more projects. The committee size grows, and it factors in people decision to accept those projects or not.
20:40:44 <markmc> there's a question
20:40:48 <markmc> do we still mean "Core"
20:40:50 <ttx> It's also an issue as we revisit our definition of "core" vs. "part of the integrated release"
20:40:52 <markmc> or "Integrated" ?
20:40:58 <ttx> markmc: ^
20:41:02 <markmc> ah
20:41:06 <heckj> heh
20:41:20 <ttx> For the Spring 2013 elections I'd like to see a system where the committee size doesn't increase if we accept more (integrated) projects.
20:41:26 <mordred> ttx: any idea what the average attendence percentage rate is?
20:41:38 <ttx> One obvious solution is to say the TC is 13 seats, make all seats elected, and have interested PTLs (from "part of the coordinated release" projects) run for election.
20:41:43 <ttx> mordred: attendence ?
20:41:48 <ttx> Last time we raised that solution it was objected that the TC could end up containing no PTL, creating various governance issues
20:41:57 <ttx> The middle-ground solution, which solves that perceived risk, would be to say:
20:41:59 <mordred> ttx: like, with 13 members, do we usually have 60% show up?
20:42:09 <ttx> mordred: I can do taht analysis
20:42:11 <ttx> no idea
20:42:20 <ttx> "TC is 13 seats, make all seats elected, have interested PTLs run for election, and guarantee that /at least/ 8 PTLs are present on the TC at any time"
20:42:30 <ttx> That way if PTLs fare well in the election you might just get more than 8 of them in the committee
20:42:37 <ttx> But if they don't fare that well, you still get the 8 most popular of them on the committee
20:43:00 <russellb> seems fairly reasonable ...
20:43:04 <ttx> thoughts ?
20:43:13 <mordred> I actually think the first one is simpler
20:43:18 <jgriffith> seems a bit odd to me, but I don't have a better solution
20:43:22 <russellb> i feel pretty confident that lots of PTLs would be elected anyway
20:43:24 <mordred> and I'm not too worried about the weird thing
20:43:24 <creiht> Seems to marginalize projects that "may not fall in line with everyone else"
20:43:25 <markmc> I prefer the first one
20:43:29 <ttx> mordred: I like the first one, but can accept the mitigated version if that alkleviates concerns
20:43:38 <annegentle-itsme> I like all seats elected
20:43:45 <markmc> but if a compromise is needed, the second is better than all PTLs having a guaranteed seat
20:43:45 <mordred> since the PTLs are elected from populace anyway
20:43:55 <annegentle-itsme> and is 13 ideal? for an odd number? More than a hung jury or some such?
20:43:59 <mordred> but yes, not strongly opposed to the compromise
20:44:04 <annegentle-itsme> or would 9 suffice?
20:44:09 * annegentle-itsme just thinking aloud
20:44:11 <ttx> creiht: I'm not sure of that. That would marginalize smaller projects, I think
20:44:14 <mordred> annegentle-itsme: that's kinda why I was asking theirry about the attendence numbers
20:44:24 <annegentle-itsme> mordred: okay, yup
20:44:25 <danwent> what about the PTLs choosing the sub-set of their group that is on the TC?
20:44:40 <notmyname> danwent: PTLs chosen fromt he TC?
20:44:41 <danwent> some PTLs may not be interested, or may trust another PTL to represent their interests
20:44:42 <mordred> danwent: kind of like the foundatoin board does for gold members
20:44:46 <ttx> creiht: personally I like to have various opinions, so i'd certainly vote for someone that provides constructuve criticism
20:44:49 <danwent> mordred: yeah
20:45:00 <gabrielhurley> my concern would be that an all-elected TC could easily skew in perspective, e.g. half the TC are Nova core, and nobody representinc the "higher level services" like Horizon, Ceilometer, etc. would be involved.
20:45:01 <notmyname> danwent: ah ok
20:45:13 <danwent> gabrielhurley: i agree
20:45:15 <jgriffith> gabrielhurley: +1
20:45:33 <ttx> gabrielhurley: good point, which the "mitigating" proposal addresses, I think
20:45:44 <mordred> gabrielhurley: excellent point
20:45:54 <danwent> gabrielhurley: but if the PTLs elected it themselves, two small projects could jointly agree on a candidate, and have a high probability of that person being selected.
20:46:04 * creiht agrees with gabrielhurley's more constructive observation
20:46:36 <mordred> danwent: I betcha if we had the ptls elect their reps, we'd use condorcet or something :)
20:46:57 <markmc> moar elections plz, thur fun
20:47:06 <annegentle-itsme> an all-elected is even more of a popularity contest to be gamed…
20:47:06 <gabrielhurley> yeah, the election process is gonna get *crazy*
20:47:12 <mordred> markmc: we could do PTL elections via gerrit ...
20:47:16 <gabrielhurley> ha
20:47:18 <heckj> heh
20:47:21 <danwent> mordred: :)
20:47:24 <markmc> mordred, what would we gate on?
20:47:29 <mordred> and then add condorcet voting to gerrit reviews!
20:47:39 <ttx> Who is firmy against the "all elected with a minimum of 8 PTLs from integrated projects" solution ?
20:47:46 <ttx> firmly*
20:47:55 <annegentle-itsme> ttx it's hard to know until "integrated" is defined?
20:48:03 <notmyname> ttx: not sure yet, but I'm maybe firmly against that :-)
20:48:04 <ttx> integrated = what the TC wants
20:48:16 <annegentle-itsme> ttx: mkay
20:48:22 <notmyname> ttx: IOW, a self-selected group
20:48:30 <heckj> IOW?
20:48:34 <gabrielhurley> just to throw out an idea, what if there were a couple of seats on the TC designated for certain functions that we deem important (a seat for docs, a seat for CI, at least one seat for "higher-in-the-stack projects")
20:48:34 <mordred> in other words
20:48:35 <notmyname> in other words
20:48:37 <heckj> h
20:48:38 <heckj> ah
20:49:02 <ttx> No, I mean, "integrated" = the set of projects we decide. What we currently call "core"
20:49:08 <heckj> gabrielhurley: I liek the idea of purposefully including some specific perspectives
20:49:19 <heckj> and I can't type worth crap today
20:49:30 <gabrielhurley> then peopple could run for those seats specifically
20:49:30 <dhellmann> What about limiting the TC members per project, like we do with classes of members on the board? Candidates could declare which projects they contribute to.
20:49:31 <ttx> but that we'll have to call something else once "core" becomes a trademark-use category
20:49:51 <ttx> dhellmann: I contribute to all of them.
20:49:54 <jgriffith> what about one elected member from each core/integrated plus CI, Docs etc and that's it?
20:50:16 <russellb> but that doesn't limit TC size
20:50:22 <ttx> jgriffith: that's ever-growing
20:50:23 <annegentle-itsme> jgriffith: I think that exposes the growth problem
20:50:23 <jgriffith> russellb: nope
20:50:28 <dhellmann> ttx, so have some seats for meta-contributors like you and annegentle-itsme
20:50:36 <annegentle-itsme> ha like growth is a problem, it's not :)
20:50:40 <jgriffith> well personally I think wer'e going to have that regardless
20:50:51 <russellb> i think growth can be a problem for a committee ...
20:50:58 <jgriffith> especially when we haven't defined how we address growth anywya and pass it on to the board
20:50:58 <ttx> I think a 15-person TC doesn't make sense.
20:51:11 <jgriffith> ttx: fair
20:51:17 <markmc> we'll be better at making quick decisions if we get a few more members
20:51:17 <annegentle-itsme> russellb: yep
20:51:29 <ttx> jgriffith: the problem will happen as soon as (if) we decide that heat and Ceilo pass incubation.
20:51:41 * gabrielhurley isn't gonna bring up how many people are on the foundation board...
20:51:46 <ttx> anyway, please think about it, we'll continue that discussion next time
20:51:47 <jgriffith> ttx: I would tend to agree, which leads back to concerns I have regarding the other issues (core/integrated status)
20:51:49 <mordred> gabrielhurley: yeah. it's too many
20:51:54 <russellb> gabrielhurley: too many :)
20:51:55 <markmc> gabrielhurley, hehe, but they're ultra agile :)
20:52:04 <gabrielhurley> haha, "ultra-agile". nice.
20:52:08 <ttx> I'd like to have it nailed before we start the Spring election process
20:52:20 <gabrielhurley> ttx: +1 to figuring it out before then.
20:52:24 <jgriffith> I'm not disagreeing with it being too many ata ll
20:52:38 <ttx> Credits to nijaba for suggesting the 'all elected with a minium number of PTLs' idea
20:52:44 <notmyname> can the charter of the TC be fulfilled without equal representation from each of the projects? our goal is to manage intra-project conflicts and the coordinated release. how can that be done without representation?
20:52:57 <jgriffith> ttx: I see that as the best alternative
20:53:12 <notmyname> if the problem is the size of the TC, then perhaps the solution is to limit what's included in the release (managed by openstack)
20:53:14 <mordred> notmyname: by the directly elected folks?
20:53:23 <jgriffith> notmyname: ++++++++++++++
20:53:36 <mordred> I think that's a thing I specifically want to avoid, personally
20:53:39 <ttx> I don't think we should limit what's in the coordinated release based on committee bloat fear
20:53:43 <mordred> yes
20:53:56 <mordred> if we limit it based on project scope bloat fear, I'm ok with that
20:54:00 <ttx> we should rather accept some loss of control
20:54:01 <jgriffith> ttx: but I argue there are bigger problems than comitte bloat
20:54:05 <mordred> sure
20:54:07 <creiht> is it possible to categorize core projects, so that there is 1 TC seat per categroy, then the rest are elected?
20:54:11 <mordred> I just want to actually argue those issues
20:54:14 <ttx> i.e. trust some people to make the right decisions
20:54:26 <mordred> and not pass the buck to the inability of a particular arbitrary committee organization to do things
20:54:29 <ttx> All PTLs would still be able to defend themselves
20:54:40 <ttx> they just might not have a vote in the final decision
20:55:05 <ttx> having a vote doesn't prevent bad things from being decided for your project anyway
20:55:05 <markmc> the TC can't jut ignore PTLs
20:55:14 <ttx> markmc: +1
20:55:33 <notmyname> ttx: true ;-)
20:55:34 <mordred> and not havint a vote has not prevented me from bitching in this meeting before
20:55:39 <annegentle-itsme> markmc: agreed
20:55:52 <gabrielhurley> it's a two-way street, the PTLs need to respect the TC's decisions, but the TC has to weigh the opinion of the PTL very heavily, whether that PTL has a vote or ont
20:55:56 <gabrielhurley> /ont/not
20:55:59 <notmyname> but then you have non-members who are effectively members anyway
20:56:00 <mordred> ++
20:56:05 <ttx> checks and balances
20:56:20 <russellb> it's like a meritocracy or something
20:56:27 <gabrielhurley> or something
20:56:31 <markmc> the TC should be about driving discussions, encouraging consensus and calling what they see as the consensus
20:56:38 <mordred> it's a somethingtocracy!
20:56:42 <markmc> if a PTL adamantly disagrees, it's hardly consensus
20:57:04 <ttx> also TC pushing a decision against a project... that's a failure
20:57:34 <mordred> ttx: well, we've done it before
20:57:44 <mordred> there have been times where consensus was impossible
20:57:58 <annegentle-itsme> so about creiht and the category idea, can you float some categories?
20:57:58 <ttx> mordred: refresh my memory ?
20:58:16 <annegentle-itsme> computing, networking, storing, monitoring?
20:58:22 <creiht> something like that
20:58:31 <ttx> annegentle-itsme: Not sure. one issue would be to let the Board of Directors end up controlling who is on the TC
20:58:37 <ttx> since they will define "core"
20:58:51 <mordred> ttx: I would like to veto that
20:59:24 <annegentle-itsme> I think the categories route stops "pet" projects -- and technical use cases become more central? Possibly?
20:59:34 <ttx> anyway, time is up, think about it (and alternate solutions) and we'll continue discussion at the next meeting
20:59:40 * annegentle-itsme thinks
20:59:47 * heckj nods
20:59:49 <russellb> kthxbye!
21:00:01 <ttx> Thanks everyone, back on getting grizzly-2 out of the door
21:00:01 * mordred dances a little bit
21:00:04 <ttx> #endmeeting