20:00:48 #startmeeting 20:00:49 Meeting started Tue Jun 19 20:00:48 2012 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:55 o/ 20:01:03 o/ 20:01:07 o/ 20:01:35 so we've got 5 so far? 20:01:36 o/ 20:01:37 need 2 more 20:01:40 need 1 more 20:01:46 step right up 20:01:49 o/ 20:01:55 sweet 20:01:55 anotherjesse_zz: is popping in too 20:01:55 still need one more - I don't count 20:01:58 http://wiki.openstack.org/Governance/PPB 20:02:01 o/ 20:02:03 mtaylor: i didn't count you this time 20:02:03 w00t 20:02:06 jbryce: :) 20:02:14 http://wiki.openstack.org/Governance/PPB 20:02:23 #topic Library/Gating Projects 20:02:29 monty: you always count to us :) 20:02:38 mtaylor: do you want to explain where you've ended up with the discussion on the mailing list? 20:03:10 should markmc join us? 20:03:15 jbryce: I think the sticking point is on a different release scheme than associated server projects 20:03:19 back! 20:03:24 how many errors on the that page can you spot ;) 20:03:25 here 20:03:53 jbryce: so, I'm not sure I've sold markmc on anything - but I believe bcwaldon is more on board with the new version of things 20:04:04 mtaylor: yep 20:04:06 anotherjesse: = ) it's a wiki page so people should feel free to update their affiliations 20:04:12 jbryce: our point is that libs require PyPI, and PyPI makes your life miserable if you want to do a complex scheme 20:04:17 short story: client versions should be there own thing and tied to neither server releases or api versions 20:04:19 mtaylor: or you're on board with my version of things ;) 20:04:23 yup 20:04:30 * mtaylor bows to bcwaldon 20:04:35 like a boss 20:04:49 o/ 20:05:10 and other than that, I think as long as we tag all releases, we can defer discussion of stable branches until we come up with a situatoin where we're actually in trouble? 20:05:12 is markmc in the other room? 20:05:28 for the record, I was thinking like markmc initially, but couldn't find a solution that would work... so I accepted mtaylor's solution. 20:05:34 nope 20:05:39 ttx: which is bcwaldon's :) 20:05:40 jbryce: nope 20:06:07 I don't know if anyone read my latest novel in that thread... 20:06:08 mtaylor: I'm fine with that - I mostly needed a tag 20:06:15 heckj: awesome. you shall have one 20:06:18 well the current state makes sense to me as well with tags 20:06:42 ++ me as well, after reading the various posts I concur with bcwaldon (much as it pains me) 20:06:50 ok. sounds like we're ready for a vote 20:06:56 whee! 20:07:02 So in summary, I think the drawbacks of doing simple versioning / release scheme are far outweighed by the convenience of using PyPI in a straightfoward manner. 20:07:02 jaypipes: what that mouth 20:07:02 wait 20:07:06 jaypipes: gah, watch* 20:07:08 mtaylor: could you propose what we're voting on? 20:07:11 * mtaylor is scared of days when mtaylor and jaypipes both agree with bcwaldon 20:07:15 notmyname: waiting... 20:07:16 :) 20:07:42 jbryce: for what you just said. an actual proposal or link to what we're voting on. not "what so-and-so said on the mailing list" 20:08:10 notmyname: good point 20:08:14 let me try to make a quick summarization for voting purposes: 20:08:16 notmyname: that's why i asked mtaylor to propose it in its current form 20:09:17 we will decouple client releases from server release, we will release client libs to pypi as they are ready and their version scheme will be standard library versioning (major version bump on incompatible api changes) 20:09:21 ttx: yeah? ^^ 20:10:02 mtaylor: ..and there will be no stable version point releases 20:10:29 oh, and there will only ever be one "stable" release of client libs, and it will be expected to support all currently supported versions of the relevant api 20:10:36 which is the longer way of saying what ttx just said 20:11:17 are we making a statement about what "currently supported" means? 20:11:23 ok. give me a minute to do the votebot 20:11:29 johnpur: was just going to ask that 20:11:34 johnpur: I don't think so 20:11:45 I think we have not made decisions on deprecating old api versions overall 20:12:06 but when we do make the decision to do that, I would not expect the client libs to need to support things we declare are now crap 20:12:23 We should queue this up for discussion 20:12:31 ++ 20:12:43 #startvote Should we decouple client releases from server releases, release client libs to pypi as they are ready, version them with a standard library scheme (major version bump on incompatible API changes), and have a single stable release of client libs expected to support all currently supported versions of the relevant API? Yes, No, Abstain 20:12:44 Begin voting on: Should we decouple client releases from server releases, release client libs to pypi as they are ready, version them with a standard library scheme (major version bump on incompatible API changes), and have a single stable release of client libs expected to support all currently supported versions of the relevant API? Valid vote options are Yes, No, Abstain. 20:12:45 Vote using '#vote OPTION'. Only your last vote counts. 20:13:10 #vote Yes 20:13:12 #vote Yes 20:13:23 #vote Yes 20:13:26 #vote yes 20:13:27 heckj: yes is not a valid option. Valid options are Yes, No, Abstain. 20:13:35 #vote Yes 20:13:36 #vote Yes 20:13:37 #vote Yes 20:13:37 lol 20:13:42 picky thing... 20:13:43 #vote Abstain 20:13:44 haha. 20:13:48 does vote have a -i option? 20:13:49 computers are awesome! 20:13:55 * ttx really wishes there was another solution. 20:13:57 clarkb: feature request - case insensitive voting 20:14:00 vishy, anotherjesse ? 20:14:05 roger 20:14:37 #vote Yes 20:15:01 vishy: last chance 20:15:13 Yes 20:15:15 sorry :) 20:15:20 #vote Yes 20:15:22 Sidenote #1: it also makes more sense to separate from parent project in case we do a common single library for all openstack stuff 20:15:25 #endvote 20:15:26 Voted on "Should we decouple client releases from server releases, release client libs to pypi as they are ready, version them with a standard library scheme (major version bump on incompatible API changes), and have a single stable release of client libs expected to support all currently supported versions of the relevant API?" Results are 20:15:27 Yes (8): anotherjesse, bcwaldon, johnpur, jbryce, vishy, heckj, danwent_, notmyname 20:15:28 Abstain (1): ttx 20:15:46 baller. we shall work on getting the bits in place to do the above. thanks all! 20:15:47 Sidenote #2: That means we'll revive the python-*client projects in Launchpad 20:16:28 #topic PPB to Technical Committee transition 20:16:31 http://wiki.openstack.org/Governance/Foundation/TechnicalCommittee 20:16:40 that link is ttx's current proposal 20:17:08 i think the most unsettled portion of it is the status of PTLs as it relates to the Technical Committee 20:17:27 which we discussed a little previously but never really reached a consensus 20:17:34 I can explain my position again 20:17:48 I think PTLs should have a seat guaranteed, they ARE technical leadership 20:17:53 what is unclear to me is whether TC == PPB? or is TC + BoD == PPB? 20:18:15 bcwaldon:++ 20:18:30 bcwaldon, heckj: that's unfair and doesn't scale, let me explain 20:18:41 johnpur: there isn't an exact equivalent, but TC is closer to PPB 20:18:59 As we split Nova into smaller bits, we can expect more than 10 PTLs, erach representing a tiny bit of code 20:19:19 A vote should represent an equal force 20:19:29 johnpur: the core project additions/removals (not incubation) will also require board approval as it affects what the trademark represents 20:19:32 ttx: I wouldnt call a person in control of a section of Nova a PTL 20:19:34 The only way to esnure that fairness is to have everybody elected, and PTLs running for a positio,n 20:19:46 ttx: I would propose a new title for those positions 20:19:54 bcwaldon: where does the bucket stop ? Cinder ? Glance ? 20:20:02 ttx: I dont follow 20:20:15 bcwaldon: do glance and cinder have PTLs? 20:20:22 jbryce: currently, yes 20:20:30 bcwaldon: or should they i suppose is the more appropriate question 20:20:35 bcwaldon: Cinder is a split of Nova. It's a full-fledged core project. I don't want to have small and bug core projects 20:20:40 I want to have core projects 20:20:44 big* 20:20:49 ttx is referring to all of the things that we've been breaking out of nova 20:21:02 There will be no correlation between the size of a core project and the fact that it is core 20:21:08 quantum too 20:21:10 so you will end up with 10+ PTLs 20:21:11 I understand, but doesnt there have to be someone in control of Nova to coordinate all the goings on? 20:21:30 PTLs for large projects will get elected to the TC anyway 20:21:35 yes, nova would continue to have a PTL 20:21:47 and PTLS for very small projects, well..; why should they get an appointed seat ? 20:21:54 ttx: what about representation for the smaller projects? especially if there are more of them? 20:22:02 I think we're talking past each other here 20:22:12 A PTL is still in charge of its project... 20:22:19 ttx: i think it's stilly to have a system that supports implicitly the idea that their *could* be another group other than the PTLs who are deciding technical decisions about those projects. 20:22:29 heckj: yes, thats my main point 20:22:36 He can participate to the meeting. I don't see why he would necessarily need to have a vote. 20:22:41 ttx: really, the TC should be PTLs + some more smart people 20:22:47 * mtaylor proposes a bi-cameral solution, with one side having proportional representation, and the other side having equal 20:22:48 ttx: because voting makes things happen! 20:23:02 bcwaldon: that's actually my preferred make up as well 20:23:11 similar to what we have now, just removing the appointed seats 20:23:21 * anotherjesse kicks me 20:23:25 jbryce: but you're missing the part about PTLs having guaranteed membership 20:23:27 OK, then I'll say that I don't thin kit's fair that vishy's voice is as important as John Griffith's. 20:23:27 :( 20:23:36 bcwaldon: no i wasn't. i agreed with you 20:23:43 it should be more important. He represents a larger project 20:23:51 jbryce: ok, I must have missed it in the three convos happening here :) 20:24:13 ttx: vish will have authority because we trust his judgement and he can sway people. 20:24:14 I understand why THIS group would prefer to keep PTLS appointed, but a bloated workgroup won't work 20:24:15 ttx: but you just said nova is going to continue to be split... 20:24:18 bcwaldon: earlier i was just trying to explain that ttx was actually talking about real PTLs and projects not sub-components of nova or any project 20:24:34 okie 20:24:43 bcwaldon: the projects will never be of equal size. Fairness is to get everyone elected 20:24:57 so if we remove the appointed seats, we now have 4 additional slots before we're back to current size 20:25:08 i don't know that we've had too much of a problem with bloat to date 20:25:11 ttx: so what happens when we get a bunch of random people elected to TC dictating what the PTLs have to do 20:25:13 one other important point 20:25:21 ttx: a new company could join tomorrow with enough voting power to install people 20:25:35 ttx: The only thing I would ask about is some sort of requirement to even run for election? 20:25:36 according to the Bylaws, the technical committee has the ability to change its make up and processes down the road 20:25:40 bcwaldon: they would elect PTLs as well 20:25:57 ttx: fair 20:26:00 The trick is to get the technical membership right, so that the same people vote for PTLs and vote for TC 20:26:03 i would trust the group to recognize if the current structure is getting so bloated as to prevent problems and make some changes 20:26:17 bcwaldon: then in the end, the TC ends up being the 9 most representative PTLs. 20:26:38 ttx: ok, I guess I'm not thinking about how many PTLs there will be down the road 20:27:09 how many more pieces do we anticipate splitting out? 20:27:10 jbryce: this is why i asked about ppb and tc equivalence, i agree with what ttx just said 20:27:12 jbryce: we have the opportunity to do it right, why not take it now ? 20:27:23 if we end up with 20 projects we are probably doing something wrong, that shouldn't be solved by not allowing PTLs in, but not allowing projects in 20:27:36 jbryce: I don't see a whole lot more splitting out than already has for core projects. I think this is a non issue 20:27:38 however, this doesn't cover the policy and global view that ppb is suppoed to own 20:27:44 ttx: depends on the definition of "doing it right" 20:27:49 jbryce: but you don't want to trust the future TC to voluntarily "limit" its reach (by limiting who is in it, it implies that current members of it vote themselves off of it) 20:27:51 * mtaylor thinks anotherjesse isn't going to accept his coffee-as-a-service project into core. cries. :( 20:27:53 Also note that PTLs are still very much in charge of their project. The TC just solves issues that are cross-project 20:28:00 mtaylor: go back to your corner! 20:28:20 anotherjesse: +1 20:28:21 TC controls "openstack", PTls control each project 20:28:21 ttx: ok, well I feel like theres already a lot of mandating that happens even though I'm Glance PTL 20:28:30 ttx: so be careful with what you say :) 20:28:39 bcwaldon: +1 20:29:04 ttx: false division - the projects are interrelated and getting more so, not less. 20:29:08 ttx: today we have an implied (maybe explicit) assumption that PTL's are solving cross project technical issues outside of "governance", right? 20:29:27 johnpur: definitely is happening 20:29:40 johnpur: yes, absolutely occuring 20:29:50 TC should add value above this level of interaction 20:30:00 how about that: the PTLs are all members of the TC, but only elected members get a vote 20:30:13 ttx: then what does membership even mean? 20:30:13 so they can participate in the discussion and influence the vote 20:30:20 johnpur: shouldn't the TC/PBB/whatever only come into play if there is a roadblock? 20:30:39 ttx: I would assume *anybody* can participate 20:30:43 ttx: open community, no? 20:30:43 thus far the discussions between projects have gone well 20:30:44 mtaylor has been participating in the discussion all day today! 20:30:51 * mtaylor does his best 20:30:52 anotherjesse: indeedly doodly 20:31:18 anotherjesse: ++ 20:31:34 anotherjesse: right. and to raise issues that individual projects/owners might not consider 20:32:01 i actually think that either model could work, but i do feel like having the PTLs involved in all of these decisions has been better for us over the past year and a half that the POC/PPB has existed 20:32:04 to guide openstack as a whole 20:32:15 What would be the alternative ? A TC entirely made of, and only consisting of, PTLs ? 20:32:22 I'm leaning towards PTLs being on the TC until a time where it is unmanagable 20:32:26 * ttx doesn't want bloat 20:32:26 and then fix it 20:32:34 PTLs plus X number of generally elected seats (4-5) 20:32:41 ttx: how many ptls will we have for the next 9 months? 20:32:52 7 20:33:00 nova,glance,swift,keystone,cinder,quantum,dash 20:33:00 if cinder makes it in 20:33:02 ttx: nova, glance, swift, keystone, quantum, horizon 20:33:08 so 6 or 7 20:33:16 I think we will be fine for the next 9 months :) 20:33:24 cinder, at least two other projects filing in incubation... 20:33:26 * heckj agrees 20:33:36 whats the time frame on forming this TC? 20:33:37 ttx: which two other projects/ 20:33:59 anotherjesse: unified cli, ceilometer, heat... 20:34:05 ttx: I understand your point, but I think you're making a mountain out of a mole hill here 20:34:27 I would argue that those aren't core 20:34:34 heckj: I would prefer that everyone is on the TC for the same reason. That sounded fair. You would get elected anyway :) 20:34:38 ttx: anotherjesse they wont be for at least 9 months 20:34:50 bcwaldon: even then, are they essential iaas 20:34:52 the current structure is 5 generally elected seats, all core PTLs, plus 4 appointed. if we remove the 4 appointed seats, we have 4 spots before we even get back to the size we are right now 20:34:56 anotherjesse: thats another discussion 20:35:04 anotherjesse: (I agree with you) 20:35:30 bcwaldon: we need to decide on the structure within the next few weeks and be ready for a transition in august to september timeframe 20:35:30 jbryce: I like that plan 20:35:44 ttx: kind of you to say, but not exactly the point 20:35:46 jbryce: If that's what everyone wants, I'll fold. I'd prefer to design a long-lasting solution rather than something we need to revisit soon 20:35:49 bcwaldon: it may slip past that by a month or so, but that's the timeline we're shooting for 20:35:50 jbryce: ok, so once we actually form this thing we've still got 6 months 20:36:27 let's ask it the other way around: what's the problem with all-elected members ? 20:36:58 some project PTL might not be in ? so what. It's not as if decisions were unanimous 20:37:00 ttx: I feel like the PTLs have already been identified as critical leadership, and their inherently *technical* skills are necessary 20:37:15 ttx: but I might just be talking myself up, here :) 20:37:30 bcwaldon: if the TC is elected by project contributors, you'll get PTL-like people on the TC 20:37:42 note that we only let contributors vote 20:38:13 ttx: that is true 20:38:14 think of it as a super-PTL vote. All contributors choose the 9 best people. 20:38:25 Instead of half of them being selecetd by subgroups 20:38:36 ttx: I'd also like to look at this more like the electoral college than the popular vote 20:38:46 ttx: I dont want a super project (nova) to have all the representation on cross-project matters 20:38:51 ttx: i think the issue is underrepresentation of smaller projects 20:39:23 jbryce: smaller projects will have to be underrepresented. If we create a project for each core plugin, there will be a lot of them 20:39:34 and it would be unfair to consider them less important than others 20:39:53 ttx: I *really* want to make sure we agree on what a PTL is 20:40:07 what is a core plugin? how is that different from a core project? 20:40:40 we have a definition and process for determining that something becomes part of "core OpenStack"...is that the same thing you're referring to? 20:41:09 jbryce: if we continue to split Nova into smaller bits (like for Cinder)... there will be a lot of new core projects. Not counting those that will file for inclusion 20:41:33 I'd hate it if we decided to reject a core project just because the TC feels crowded 20:41:50 ttx: I would too, and if we got to that point we would have to fix the TC 20:41:55 when i asked earlier what else might get split from nova besides networking and block storage, it didn't seem like people had a really long list 20:41:59 That's why I recommended a fixed number and get them all elected 20:42:10 That's fair and it scales. 20:42:18 ttx: I still dont agree that its fair 20:42:36 ttx: well, its "fair" but it may not give the best representation 20:42:36 can we take a straw poll to see where people are standing on the idea of having PTLs plus generally elected seats for the makeup of the TC? 20:42:56 I'm sure many people have alt+tabbed away by this point :) 20:43:02 bcwaldon: I don't think it's fair that memebrs of smaller projects, or members of multiple projects, get multiple attempts to select their TC member 20:43:12 e.g. the Technical Committee would consist of all PTLs plus 5 generally elected seats 20:43:24 bcwaldon: no joke 20:43:35 nah. this is where the action is 20:43:37 ttx: that's an odd way of looking at PTL to TC relation 20:43:41 mtaylor: you dont count! 20:43:49 ttx: the PTL position is more important than the TC imho 20:43:57 bcwaldon: fairness: basically, the vote of a strong contributor to Nova has less weight than the vote of a small contributor to cinder and glance 20:44:07 anotherjesse: +1 20:44:08 PTL is about leading a project, people don't become active in many of them to try to get TC or PBB or whatever 20:44:53 ttx: but if we segment up Nova, the weights will even out 20:45:26 bcwaldon: you still get more power if you're a small contributor to all projects rather than a big contributor to all of them 20:45:40 err... 20:45:40 ttx: the weight should be about how wise/practical/... the person is, not the value of their project. If vishy was a total asshole and didn't try to work with the other projects he wouldn't have the same position 20:45:52 bcwaldon: you still get more voting power if you're a small contributor to all projects rather than a big contributor to only one of them 20:46:10 ttx: ok, well I'm at the point where I'm going to #agree to #disagree 20:46:57 bcwaldon: I think all-elected is the only way to have fair representation. That said, we can bend the rule if we thing something else is more important 20:46:57 so.... 20:47:09 the PTLs are elected 20:47:12 ttx: I know, I've been listening to you 20:47:12 like making sure all PTLs as leaders of this community will be at TC 20:47:39 heckj, notmyname, vishy: do you have an opinion on this? 20:47:43 ttx: the ptl's are all elected now. 20:47:50 ttx: so all elected means getting rid of appointed as well? 20:48:16 danwent: sure 20:48:19 danwent: appointed seats are going away in either scenario 20:48:23 jbryce: All PTLs + 5 generally elected seats 20:48:24 it sounds like the tc is simply aggregating the ptl's and giving them (as a group) a wider charter 20:48:34 ttx: k, wasn't sure 20:48:40 options are a) 9 seats, all elected generally or b) PTLs plus 5 generally elected seats 20:49:05 jbryce: PTLs should have a seat. voters should have a commit in the past 2 release cycles. no proxy votes 20:49:15 do we think that the non-ptl members of the PPB are adding value? 20:49:16 jbryce: you're proposing two different sizes of TC, yes? 20:49:27 johnpur: speaking as one ;) 20:49:30 bcwaldon: yes. one is fixed and one is variable with the number of projects 20:49:31 johnpur: yes 20:49:42 do we have a proof-point how "how large is too large"? Or just guessing? 20:49:47 johnpur: when they attend... :-) 20:49:48 this may help in the decision 20:50:03 jbryce: kk, just pointing out that the latter will be 11-12 for the G-whiz time frame 20:50:14 bcwaldon: correct 20:50:21 danwent: generally about 10-12 is the max effective size of a group 20:50:37 notmyname: seems reasonable 20:50:47 notmyname: citation needed 20:50:51 danwent: we've been 14-15 for around a year 20:51:07 bcwaldon: http://en.wikipedia.org/wiki/Dunbar%27s_number 20:51:17 jbryce: yet we struggle for qourum at the start of meetings? 20:51:24 didn't realize we were that big. 20:51:30 notmyname: well done 20:51:51 danwent: we haven't had that problem for a while. i think that was more process failure on my part than our size 20:52:00 dunbar's number is 100-200 :) 20:52:02 bcwaldon: actually, I think that's the wrong reference, but the principle is there :-) 20:52:13 that's a lot of ptls! 20:52:18 notmyname: wait 20:52:23 notmyname: yes, just read into it 20:52:26 notmyname: 150! 20:52:54 Last remark: should the "gating projects" that we just decided would exist as official projects have leaders ? Would they be considered "PTLs" and get a seat to the TC ? 20:53:22 sigh. I'd prefer if we didn't have to artifically limit the number of projects and leaders just to avoid committee bloat 20:53:25 ttx: I hope not 20:53:26 ttx: did I miss some context for that first question? 20:53:48 ttx: are they official core projects? 20:53:55 * anotherjesse missed somethign 20:54:01 ttx: agree. we need a system that scales to the natural size of the openstack project 20:54:02 bcwaldon: previous topic. Proposal created "library projects" and "gating projects" as official openstack projects 20:54:03 i thought they were getting a non-core designation 20:54:13 ++ 20:54:15 so PTLs = core only ? 20:54:24 other projects don't get to have a leader ? 20:54:37 or they are not 'important enough' to have a seat ? 20:54:40 anybody can have any leader they want 20:54:51 ttx: maybe not a PTL in the governance we set up 20:55:08 otherwise we'd just call them core projects 20:55:21 ok, so your governance is also about deciding which kind of leaders actually should have a reserved seat on the TC 20:55:42 ttx: I'd call that a side-effect, but yes 20:55:50 one way to look at this is as a representative democracy… with PTLs having a spot on TC, each developer is guaranteed to have a representative on the TC that they work closely with. Albiet with skewed voting power, as ttx notes. Seems new approach makes it easy for a dev not to really know anyone on the TC, especially if they contribute to a smaller project. Not sure if that is a goal we consider important though. 20:55:51 so only PTLs-as-in-core-project 20:56:12 danwent: good summary 20:56:28 Like I said, I'm ready to accept some skew... I just want to do it for good reasons 20:56:34 ttx: that was my thought. that's why i keep tying it back to the core project designation 20:56:57 the purpose of the community and development process is to produce the core software projects 20:57:08 2 minutes, turkish 20:57:11 not because some people are afraid to lose their seat, but because we actually want that kind of representation 20:57:12 lots of other activities and projects related to that and that make that work 20:57:54 jbryce: what size would be the limit at which you would reconsider that PTL+5 model ? 20:58:31 ttx: dunbar's number? = ) 20:58:36 haha 20:58:37 i don't have a specific number in mind 20:58:38 lol 20:58:54 lol 20:59:08 frankly, I would expect the PTLs would get elected anyway, as proved by last election (where some PTLs were also running for the free seats) 20:59:09 we've moved to having an average of about a meeting a month and with proper notice have been able to reach quorum and have good discussions 20:59:23 so i don't think even 15 is too many 20:59:28 the benefit of the "pure 9" model is that it has bloat-containment built-in 20:59:33 true 20:59:39 well...we're out of time 20:59:55 i'll send something to the list to follow up 20:59:56 thanks everyone 20:59:59 #endmeeting