20:01:53 #startmeeting tc 20:01:54 Meeting started Tue Oct 21 20:01:53 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:57 The meeting name has been set to 'tc' 20:02:02 o/ 20:02:02 Our agenda for today: 20:02:09 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:16 First meeting of the Kilo season ! woohoo 20:02:18 o/ 20:02:24 \o/ 20:02:27 #topic Welcome new Kilo TC members 20:02:35 welcome back jgriffith 20:02:40 welcome jgriffith 20:02:41 #link https://review.openstack.org/129274 20:02:47 jgriffith: o/ 20:02:47 welcome jgriffith! 20:02:49 This is housekeeping, will approve now unless someone complains 20:02:59 :) Thanks!!!! 20:03:40 #topic Election of the Kilo TC chair 20:03:46 Is anyone else interested in chairing the TC ? 20:03:51 I pushed as a candidacy: 20:03:57 #link https://review.openstack.org/129275 20:04:01 o/ 20:04:12 not really here, but I support ttx 20:04:34 mordred: heh I thought you were volunteering yourself 20:04:40 If you don't want to propose yourself as alternative, just vote on that one 20:04:43 ttx: keep on keeping on 20:05:03 well, it's now part of my job description, so I guess my employer agrees 20:05:04 ttx: you've done an awesome job, thanks :) 20:05:12 * dhellmann imagines "stay calm, and thierry on" t-shirts 20:05:23 dhellmann: lol 20:05:23 lol 20:05:35 dhellmann: nice 20:05:49 Cafe press someone? 20:05:52 * devananda lurks in this meeting while lurking in a f2f meeting 20:05:56 ttx: congrats looks like you have enough votes 20:06:06 yep, approved 20:06:08 ttx: grats! 20:06:15 Thanks everyone! 20:06:28 ttx: thank you for signing up for another round :-) 20:06:44 I won't stop now that it's becoming fun 20:06:58 #topic Cross-project workshops track scheduling 20:07:05 So... We need to work this week on selecting the cross-project workshops 20:07:12 We have 18 40-min slots available 20:07:16 And a lot of proposals @ 20:07:21 #link https://etherpad.openstack.org/p/kilo-crossproject-summit-topics 20:07:30 Who is interested in working on the final selection ? Last time I did it with Russell, wouldn't mind rotating 20:07:32 I'd be happy to help work on it 20:07:39 happy to help 20:07:43 I can too 20:07:44 last time really everyone participated 20:07:52 or most at least 20:08:02 etherpad, where everyone left a -2/-1/0/1/2 score and comments 20:08:08 and that got us most of the way there 20:08:08 i would like to help 20:08:20 i thought the process last time worked well 20:08:24 I'd like to be involved, too 20:08:24 Hmm, ok, so we could etherpad it into shape 20:08:25 I've added my thoughts and interested in tags in there... 20:08:26 do we know how many are on there? I scanned it earlier today 20:08:32 yeah, let's etherpad it up 20:08:52 line 71 can be removed unless you want to keep it for tracking purposes 20:08:56 and then who wants to work on the synthesis ? russell & mark ? 20:09:02 despite all the discussion of big-tent openstack on the ml 20:09:05 just need someone to organize the etherpad, and then collect results, help figure out things in the grey area, figure out the proposed schedule 20:09:12 there is only one session about fixing testing: Implications of moving functional tests to projects 20:09:17 ttx: works for me 20:09:20 seems like we need more there 20:09:21 API working group also got a slot 20:09:24 ttx: sure 20:09:28 vishy: +1 20:09:33 vishy: makes a good point 20:09:39 I've been away, so not clear n if/what plan there might be 20:09:44 vishy: could also be done as a QA session 20:09:59 docs does not have a separate track so cross-project is it for docs 20:09:59 #action all TC members to weigh in on therpad 20:10:05 vishy: i don't think the big tent is about fixing testing; that's one very small part. 20:10:07 ttx: but if the proposal is moving some of it to projects it's kinda "anti-QA" :) 20:10:12 ttx: what kind of timeline do we have for this 20:10:17 i'm actually traveling the rest of this week ... 20:10:19 #action russellb and markmcclain to crystallize it into a schedule near the end of week 20:10:27 ha 20:10:28 ttx: i think the functional testing cross-project item is important 20:10:38 ttx: i'm hoping you are not suggesting scheduling that as a qa session 20:10:40 we need final schedule by Tuesday next week 20:10:55 jeblair: that was not my suggestion 20:11:18 ttx: okay; what were you suggesting be a qa session? 20:11:33 jeblair: vishy was saying only one session was proposed about testing -- I expect there to be plenty of QA sessiona bout testing. 20:11:35 jeblair: that is one part that will require a lot of cross-project discussion, but my point was that there are no other sessions about other parts (that I could find) 20:11:46 oh maybe API working group didn't get a separate session. 20:12:10 vishy: *nod* do you think something is missing? 20:12:15 API wg definitely needs a slot 20:12:40 +1 20:12:47 yep ttx 20:12:57 so how about everyone go through and give some -2/-1/0/+1/+2 votes by the end of the week? 20:12:58 russellb: so you can't really work on it by the end of week ? 20:13:00 and honestly the API docs/specs could go in API working group. 20:13:04 and then we can make the schedule monday/tuesday? 20:13:11 mostly it's about consolidation agreement 20:13:13 or you think we should expedite further? 20:13:14 russellb: wfm 20:13:29 no, scheduling on Monday/Tuesday sounds good to me 20:13:35 Can someone guesstimate a count? 20:13:49 annegentle: count? 20:14:06 jeblair: I don’t have any specific topics offhand, but maybe a general big-tent topic to discuss changes 20:14:18 annegentle: we have 32 proposals 20:14:20 We have 18 40-min slots available 20:14:35 maybe it will be clearer after we discuss/vote on the dhellman proposals 20:14:38 thanks dhellmann (nice way to apply technology to that question) 20:14:49 annegentle: automate everything 20:15:05 russellb: oh and we have some time periods where only two run in parallel, and some time priods when 3 run in parallel 20:15:17 fun 20:15:27 the idea being to give the slots where only 2 sessions run in parallel to topics we want to maximize attendance for 20:15:28 we can sort that out monday once we have a list 20:15:31 oh criminey 20:15:34 yep, fun 20:15:49 OK, I think we have a plan for this 20:15:57 worst case scenario we close it at the TC meetign next week 20:16:04 k 20:16:09 so we just need votes on the etherpad by friday 20:16:10 ayup 20:16:12 to start 20:16:15 yes 20:16:26 o/ 20:16:40 ttx: is there pod room for cross-project spillover? 20:16:42 #undo 20:16:42 Removing item from minutes: 20:16:54 #action russellb and markmcclain to crystallize it into a schedule on Monday/Tuesday next week 20:17:12 annegentle: there are pods. 20:17:37 ok, next topic... 20:17:43 #topic TC-owned repositories 20:17:56 We have a few governance changes related to TC-owned git repositories 20:18:07 Those currently appear nowhere, and don't technically belong to programs.yaml 20:18:12 * Add list of repositories owned by the TC (https://review.openstack.org/125733) 20:18:25 This review ^ adds the file describing those. 20:18:28 The next two are adding two repos: 20:18:33 * Add a new openstack-specs repo under the control of the TC (https://review.openstack.org/125509) 20:18:43 * Adds a new api-wg repo under the control of the TC (https://review.openstack.org/129188) 20:18:58 20:17 < clarkb> jeblair hrm I can probably swing something later in afternoon. maybe 3ish? 20:18:59 I'm fine with considering them part of the openstack mission and justifying their presence in the openstack/* namespace with a TC stamp for the time being 20:19:04 (oops) 20:19:18 since that's what our current governance mandates 20:19:35 i think that's a swell idea 20:19:45 sounds like a good workaround 20:19:49 i think giving the api wg a tc charter is a good idea too 20:19:52 we should document it to make it official 20:20:01 jeblair: ++ 20:20:05 it == the ownership plan 20:20:16 so when reviewing patches to create new tc repos 20:20:17 Approving the first one since it has enough 20:20:23 where do I look for the mandate? 20:20:28 the tc meeting logs? 20:20:31 so the tc is ultimately accountable, or the tc is ultimately governing? 20:20:39 so, api wg proposes content, but TC reviews/approves? 20:20:55 anteaya: in the governance repo ? 20:21:13 anteaya: the new file created by https://review.openstack.org/125733 20:21:13 ttx okay I shall refer to the governance repo 20:21:26 russellb: personally I see it more as a working group ,they build recommendations 20:21:31 I was thinking of it like api-wg proposes guidelines, TC or api-wg can +1, with one person being the final +1 like how ttx serves on TC voting 20:21:34 dhellmann: awesome 20:21:40 then we'll see if we should force it down anyone throat 20:21:51 but I'd rather not ti 20:21:54 to* 20:22:11 how do we know how many votes are sufficient on reviews? 20:22:24 I'd let the wg organize itself 20:22:28 annegentle: would be up to the API WG to determine a policy. 20:22:36 jaypipes: ok that's fair 20:22:38 i guess my only concern is that we're empowering a group, without the group having done work yet to build their credibility 20:22:42 Frankly, it's not the first time this working group is created 20:22:52 so I'd ratrher let them start producing something 20:22:55 yeah I'd rather support success :) 20:23:07 we don't bless a project the day they create a wiki page, we expect them to write a bunch of code and build a community around it 20:23:08 we have had API czars before. 20:23:10 russellb: well, we're empowering a group to create guidelines, not enforce those guideliens. 20:23:17 they just never took off 20:23:30 jaypipes: fair, though it's implied everyone should follow them, right? 20:23:46 russellb: if they come up with something we think is a good idea? 20:23:49 russellb: at this point, I wouldn't say that 20:24:02 I want to let them create something 20:24:05 maybe the policies in this specs repo aren't what people should follow, but it gives them a place to create those policies? 20:24:08 If we like it, we can push it forward 20:24:18 dhellmann, ttx: ++ 20:24:28 if we're just creating a repo that's fine 20:24:31 russellb: eventually I would like the guidance from the WG to be enforceable, but the guidelines should stand on their own merit. the problem is, who decides if the guidelines have merit? 20:24:36 At this point it's just "creating a repo" yes 20:24:45 jaypipes: we do, i suppose 20:24:53 and let them produce awesome recommendations 20:25:04 right, we'll have to make a decision about what to do with the policies after they exist 20:25:05 russellb: right, which is why it's proposed to go under the purview of the TC's repos. 20:25:20 which is why my first question was, who approves the contents of the repo 20:25:27 russellb: frankly, I'd just be happy to have an agreed-upon place to put API guidance proposals :) 20:25:30 russellb: right, that's what I was wondering too 20:25:55 The repo is a step up from the wiki page 20:25:57 russellb: they build the recommendation. Then we see if we like it enough to push it 20:26:00 with reviews, etc. 20:26:00 russellb: the working group will approve them, though I'd like the TC to have voting rights in all working groups. after the proposed policies are defined we should probably put them in the governance repo 20:26:45 in addition to the name of the repo that can be created, should we also have the name of someone infra can seed the core group for the repo? https://review.openstack.org/#/c/125733/1/reference/technical-committee-repos.yaml 20:26:58 ok, the end goal workflow just isn't totally clear to me 20:27:23 anteaya: how about the owner of the change, unless specified otherwise in the commit message ? 20:27:24 russellb: I agree, we're still figuring that out 20:27:39 ttx if we like that, that is fine with me 20:28:04 russellb: at this point they need a git repo to experiment the process 20:28:13 fair enough. 20:28:19 anteaya: please also add the tc group (whatever it's actually called) to the new groups that can vote +2/-2 on these new repos 20:28:26 so how about we let the wg work on creating something, they come back to us when they are done, and we approve it. we try to keep in touch in the meantime. but we make it clear that a commit landing in that repo at this point does not make it policy. 20:28:35 jeblair: ++ 20:28:40 jeblair: wfm 20:28:41 It's ultimately under our control, so we can "fix" it if we don't like how the organize 20:29:16 Any TC member volunteering to keep track of where this is going ? jaypipes maybe ? 20:29:17 ttx: that's a bit... unsettling or demotivating for the wg 20:29:21 anything other than a wiki page works for me. :) 20:29:33 ttx: yes, I will take point on it. 20:29:35 dhellmann: does the tc group consist of the members of the tc? 20:29:39 annegentle: I think it's less demotivating than waiting before giving them a git repo :) 20:29:46 dhellmann: I'm guessing yes, but would like to be sure 20:29:47 the suggestion of just using openstack-specs kinda makes sense too 20:29:50 but i don't care much either way 20:29:58 anteaya: yes, there must be a group in gerrit somewhere that has all of the tc members in it, and that's the one I mean 20:30:00 maybe we should propose a commit to governance chatering the api wg and recording this intent? 20:30:04 russellb: that might be a good way to look at it also 20:30:06 #info jaypipes volunteers to report back on TC with API WG progress 20:30:07 anteaya: whoever can +1/-1 on the governance repo 20:30:14 jaypipes: thanks 20:30:19 jeblair: ++ 20:30:19 no problemo. 20:30:27 dhellmann: https://review.openstack.org/#/admin/groups/205,members 20:30:27 jeblair: +1 20:30:31 * ttx looks at vote counts on that repo 20:30:32 api working group is basically a specialty for cross-project 20:30:37 anteaya: that's it 20:30:43 great, thanks 20:30:57 We have 8 YES there, so I'll approve it now 20:31:05 unless someone screams 20:31:28 ok done 20:31:39 that should unblock the repo creation 20:31:47 #topic Other governance changes 20:31:55 * Move config to system-config in the infra program (https://review.openstack.org/129438) 20:32:03 This one is housekeeping, will approve unless someone disagrees 20:32:14 we're totally not renaming it back ;P 20:32:22 good to know! 20:32:39 * Add heat-translator to the Heat program (https://review.openstack.org/127349) 20:32:46 This one has Heat PTL's +1 on it, will approve unless someone complains now 20:33:11 #topic Stalled changes 20:33:25 * Remove support for vendor extensions from our code (https://review.openstack.org/122968) 20:33:38 I abandoned my one of those 20:33:50 Not a lot of progress there... 20:33:58 mikal: yes, I cleaned it up from list 20:34:04 oh, this has been revised 20:34:14 yes 20:34:17 it's no longer a flame but a serious suggestion 20:34:27 Oh, interesting 20:34:30 I was avoiding the flame 20:34:31 looks less like a flame yes 20:34:59 less flamey, still quite woolly 20:35:03 i will take a look at it again, because i think the idea merits consideration 20:35:07 * dhellmann wonders who dared mordred to use whereas 20:35:21 dhellmann: I believe it was vishy 20:35:27 so, let's keep this one active ? 20:35:30 zaneb: that sounds like something he'd do 20:35:35 +1 20:35:51 * Add a docs environment to the testing interface (https://review.openstack.org/119875) 20:35:58 This one also failed to pick up support... what's the next step there ? 20:36:19 * jaypipes might have to reconsider that review just because of the use of the phrase "incent the vendor to align with gusto." 20:37:02 ttx: poke mordred and see if he has further thoughts on it? 20:37:18 ttx: I think we mostly agreed with jeblair to leave the "docs" target as optional 20:37:19 yes, I guess... 20:37:46 I'm okay with docs target as optional 20:37:51 #action ttx to reach to mordred to check for further thoughts or abandon on https://review.openstack.org/119875 20:37:58 if it had one more "Whereas" line I would've been +1 20:37:58 I cna change my vote 20:38:01 * Naive script to verify extra-atc foundation status (https://review.openstack.org/121696) 20:38:03 and if it's optional we don't have to include it in the guidelines 20:38:19 ttx: I just abandoned that one 20:38:19 was abandoned 20:38:30 I'll try to find time to resubmit it to the other suggested repo 20:38:37 I support that tox -edocs exists 20:38:55 alrighty. I feel like we are much more efficient in Kilo, we processed like 12 chnages in 39 minutes 20:39:17 Now for a funnier topic 20:39:19 annegentle: ++ (and i use it!); i just want to make sure our deliverables are consistently generated 20:39:41 #topic Governance structure reform 20:40:05 So we obviously don't have the time to thoroughly discuss those proposals in the remaining 20min 20:40:13 we have two things up for review: 20:40:20 * Doug's series (https://review.openstack.org/#/q/status:open+topic:big-tent,n,z) 20:40:27 * Jay's alternative (https://review.openstack.org/126582) 20:40:38 would everyone prefer to continue reviewing my series as a series, or should I squash them into one commit? 20:40:41 Personally I feel like they are both going in the same direction, but from opposite ends 20:40:50 dhellmann: I don't mind the series, personally 20:40:52 dhellmann: squash please. perhaps 2 changes 20:41:01 i really like that dhellman (and then jaypipes) put those changes up for review; i do think that was the natural next step 20:41:01 but in my mind it has exposed that we may still have some big-picture ideas to agree on 20:41:01 so maybe we can discuss those at the summit to agree on high level "requirements" and then further refine them in review? 20:41:05 wouldn't mind squash either 20:41:13 I'd like to discuss the premise of dhellmann's if we have time for that 20:41:21 jeblair: yes, that's exactly why I put the changes together :-) 20:41:21 jeblair: ++ 20:41:25 jeblair: ++ 20:41:29 Doug's incrementally changes the governance to introduce big-tent things in 20:41:32 Jay's rips off the charter first and then rebuilds 20:41:36 But the end result is not that different. 20:41:40 jeblair: why not discuss on the mailing list? 20:41:42 (imho) 20:42:10 ttx: do we have a formal in-person meeting of the tc scheduled for any time during the summit? 20:42:28 I think I have an empty slot on Wednesday at 4am 20:43:09 I feel like face to face is going to go better than yet another 100 email thread 20:43:10 ttx: lol 20:43:18 mikal: +1 20:43:24 But yeah, I don't know when that would happen 20:43:28 mikal: yeah, but if we don't actually have a scheduled meeting it's going to be 100 f2f meetings 20:43:31 But I think my underlying concern here is this: 20:43:35 f2f ++, with follow up being changes to (or new) patches to governance repo 20:43:37 I think we need to converge to a single proposal and then expose it to ML 20:43:38 mikal: maybe for you, but shouldn't the whole community be involved? 20:43:41 We're trying to solve our own failure of leadership with yet more governance 20:43:43 sounds like great dinner conversation :) 20:43:44 That's wrong 20:43:47 Foood fight!! 20:43:47 We should just lead more effectively 20:44:10 zaneb: maybe, we certainly shouldn't exclude them 20:44:10 mikal: I don't see it as failure of leadership 20:44:15 mikal: I wouldn't say "more governance" tbh 20:44:17 I see is as incredbile growth 20:44:19 zaneb: however, the TC needs to work out waht they think first 20:44:26 resulting from great leadership 20:44:30 mikal: we are evolving our govnernance in response to growth. 20:44:36 mikal: I dont know whether it's more or less gov 20:44:40 zaneb: i generally consider that summit sessions do not exclude our community 20:44:41 ttx: I like your proposal of solidifying a bit and going to ML 20:44:41 but it's different 20:44:46 I think requirements first is a good discussion to have. 20:44:48 I think the general issue was discussed on ML threads already 20:44:49 ttx: but going to ML with structure and boundaries :) 20:45:01 the next step is a formal proposal 20:45:02 mikal: I largely agree, but think some of the proposals will also make that easier. 20:45:08 mikal: actually, my proposal rips away governance, not adds to it. 20:45:18 that can be reviewed on Gerrit/discussed on ML 20:45:21 rather, rips away rigid structure, rather than adds to it. 20:45:32 jeblair: interesting, should we put this on the cross-project session schedule? 20:45:36 because another round of talking generally about the problem won't really help 20:46:00 I'd say that both of the proposals on the table today remove governance 20:46:04 I like the idea of a cross project session 20:46:13 dhellmann: sounds like a good idea 20:46:17 dhellmann: +1 20:46:18 * dhellmann adds to the etherpad 20:46:24 I think I suggested such a workshop 20:46:27 already 20:46:30 * ttx checks 20:47:21 ttx: #12? 20:47:29 "growth challenges" 20:47:33 yes, including 12.5 20:47:45 "13 kids and counting"? 20:48:29 jaypipes: you mean 120 kids? 20:48:40 dhellmann: so maybe just +1 that? Or build upon it ? 20:48:55 we're up to 20 rest api definitions if you include incubating 20:49:05 ttx: OK 20:49:22 At this point it's also fine of others want to push solid proposals up for review, like Doug and Jay did 20:49:36 Good to see what the various options are 20:49:45 13 was referring to the TC membership :) 20:49:51 So plan is like this 20:50:08 1. Big ML thread about the problem (done) 20:50:28 2. Formal suggestions up on review (in progress) 20:50:40 3. Workshop on potential convergence (Paris) 20:51:16 4. Converged plan proposed on review/ML for further discussion (if we converge) 20:51:37 Sounds good to me 20:51:40 ++ 20:51:56 I'll try to address all of the comments on my patch series and squash it together into a smaller number of changes before the summit 20:52:06 revolution is difficult, but Paris is the right place to do it. 20:52:09 dhellmann: thanks, I'll find it easier as well 20:52:15 ttx: +1 20:52:27 #topic Open discussion 20:52:52 I have one question (which I'll also ask the PTLs in the next meeting) 20:53:14 The M design summit time span 20:53:19 That's the one after Vancouver, located in APAC 20:53:26 The main conference will happen Tuesday - Thursday 20:53:35 Monday will have Ops Summit, analyst day, and other smallish pre-summit things 20:53:45 Foundation staff needs to close on the contract and asks when should design summit be ? 20:53:49 Friday off? :) 20:53:53 We can do Tuesday - Friday, but then we fully overlap with the conference, which may impact the PTLs ability to present at the conference 20:54:02 We can do Wednesday - Saturday, but then... Saturday. Long week. 20:54:12 We can do Monday, Wednesday-Friday (break on Tuesday), too. But feels weird. 20:54:21 what did we do in hong kong? 20:54:22 What is your general preference on that ? 20:54:28 * dhellmann can't remember yesterday 20:54:32 wed-fri 20:54:32 all-cross-project by M :) 20:54:33 can we do monday - thursday? just to try the opposite? 20:54:50 only mid-cycles for the six months prior 20:54:53 vishy: I don't like that, because everyone shows up on the design summit 20:54:55 mon-thurs, or tues-fri 20:54:56 i guess that doesn’t really help 20:55:01 we diud that once (oin POrtland) 20:55:02 basically, anything but making the week 6 days 20:55:04 i've just accepted that conferences are basically going to be sun-fri 20:55:08 russellb: yup 20:55:16 russellb: +1 20:55:18 i like the monday, w-f idea 20:55:21 I'll keep pushing for four days 20:55:27 dhellmann: iirc we did Tue-Fri in HK 20:55:28 accept the overlap 20:55:35 cuz in APAC for many of us it's 6-7 days as is 20:55:50 and joint tc+board meeting on sunday 20:55:52 do they have any candidate cities yet? 20:55:52 so that's another day 20:55:57 sooo long 20:56:05 russellb: I guess the board thing could be on the Monday there 20:56:06 annegentle: do you think if the sessions were all cross-project that would make it easier for ptls to present? 20:56:20 vishy: yes, but won't say until contract is signed 20:56:21