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