20:01:26 #startmeeting tc 20:01:27 Meeting started Tue Feb 18 20:01:26 2014 UTC and is due to finish in 60 minutes. The chair is markmc. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:31 The meeting name has been set to 'tc' 20:01:31 o/ 20:01:41 our agenda: 20:01:45 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:01:52 #topic DefCore subcommittee status 20:01:52 #link http://lists.openstack.org/pipermail/openstack-tc/2014-February/000532.html 20:01:59 ok 20:02:05 mikal, you have a gerrit review ? 20:02:09 markmc: want me to talk to this one? 20:02:13 sure, please do 20:02:21 o/ 20:02:25 o/ 20:02:34 markmc: yep, there is a gerrit review for a _draft_ response to the DefCore committee's request at https://review.openstack.org/#/c/74483/ 20:02:41 Sorry it hasn't been up for very long 20:03:07 #link https://review.openstack.org/74483 20:03:07 There was also a desire to ask the TC how they felt about both of our delegates for the DefCore committee being from Rackspace 20:03:18 We want to avoid any appearance of trying to stack the conversation with Rackers 20:03:51 mikal, how about you talk through the essential elements of the draft ? 20:03:53 annegentle: you around? 20:03:57 * markmc clarifies 20:04:02 markmc: sure, that makes sense 20:04:10 this is a draft response from the TC to the DefCore committee's request 20:04:16 So. I think the main thing in the draft is that we want to break the problem up. 20:04:20 that we look at this "designated sections" thing 20:04:38 There isn't a consensus on how to deal with "designated sections" and there isn't a lot of time for icehouse 20:04:46 so conclusion, focus on the API testing bit first 20:04:55 So we propose that we do the bit we do agree on for icehouse, and iterate in later releases 20:05:01 russellb: yeah 20:05:08 Could we come up with some altenatives? 20:05:11 o/ 20:05:25 zehicle_at_dell: alternatives to designated sections? 20:05:27 I'd like to see what options on designated sections are being considered, it would help 20:05:40 not alternative to, but alternative definitions 20:05:50 zehicle_at_dell: well, the debate is a bit more fundamental that that unfortunately 20:06:00 not surprised 20:06:00 zehicle_at_dell: there's a number of unanswered questions around the designated sections thing in the draft 20:06:01 zehicle_at_dell: its mostly about "are designated sections a good idea" 20:06:19 mikal: and right, it's quite fundamental 20:06:29 I think perhaps because the review is only a few minutes old 20:06:32 I'd put it like this - API testing around interop is our priority 20:06:37 It might be fair to ask everyone to read it and comment there 20:06:45 And perhaps we can iterate in the review 20:06:50 And finalize at the next meeting? 20:07:01 russellb, did I miss this from last meeting? 20:07:04 and the "include the entirety of the code" provision in the trademark rules should suffice until the API interop issue is tackled 20:07:13 even working out details of the API testing seems aggressive for this timeline, so focusing there seems like a good idea 20:07:33 zehicle_at_dell, to be clear - we're just introducing a proposed draft 20:07:43 zehicle_at_dell, everyone on the TC still needs time to consider it 20:07:47 +1 20:07:51 markmc: yes, its entirely possible the TC will reject this draft 20:07:57 zehicle_at_dell, and yes, I think this reflects the discussion last week 20:08:16 I've tried to represent everyone's expressed points of view, even where I don't nessesarily personally agree 20:08:21 But that doesn't mean I did it right 20:08:23 markmc, I know that these things take time. not trying to rush it. The first pass from DefCore will be "provisional" for Havana 20:08:26 ok, any first reactions from TC members ? 20:08:30 and then we'll iterate to catchup 20:08:46 * russellb is happy with the draft, but had a chance to read it earlier 20:09:02 * dhellmann is going to need time to digest it 20:09:10 yeah, I need to re-read too 20:09:12 sure, makes sense 20:09:15 I think that's very fair 20:09:18 yeh, reread definitely in order 20:09:24 This isn't an attempt to ram something through 20:09:27 I reckon it's important we not bikeshed the details on this 20:09:29 zehicle_at_dell: we do want to help answer the questions, we're trying to focus representatives and make sure we understand the request and possible paths 20:09:37 that we make sure we're capturing rough consensus 20:09:38 markmc: yeah 20:09:43 thanks, can someone shoot a link to the draft? 20:09:45 markmc: +1 20:09:50 #link https://review.openstack.org/#/c/74483/1/resolutions/20140211-tc_defcore_response 20:09:52 zehicle_at_dell: https://review.openstack.org/#/c/74483/ 20:10:08 zehicle_at_dell: noting that the defcore committee should remember this is a draft if they read it... 20:10:16 zehicle_at_dell: i.e. the TC might pivot 20:10:36 jeblair, vishy, any first thoughts ? 20:11:15 markmc: it seems very well written. i think i need to curl up with it though, and may have some questions later. 20:11:29 jeblair, cool, enjoy and stay warm :) 20:11:32 jeblair: you take gerrit to bed at night?!? 20:11:34 take it out to dinner 20:11:35 haha 20:11:42 markmc: still looking 20:11:44 maybe for a walk on the beach 20:11:46 vishy, cool 20:11:48 LOL 20:11:59 ok, the other thing on this that annegentle raised and mikal mentioned 20:12:04 Well, perhaps we can come back to first impressions at the end of the meeting? 20:12:18 if mikal and annegentle are the TC's reps on DefCore 20:12:27 then it may appear odd that both are from RAX 20:12:41 the fact that it didn't occur to me makes me think it's a non-issue 20:12:58 I think even having this dicussion helps 20:12:59 but anyone think we should add someone, or replace someone? 20:13:01 yes, that wasn't the intent, but then we looked at other backup combos and it was nova-heavy or vendor-heavy or just heavy :) 20:13:04 If we want to keep going with these people 20:13:08 At least we've discussed it 20:13:10 markmc, mikal: mostly i wonder how does this impact the defcore plan? if this section is missing; what portion of the actual openstack code base are trademark users required to run or distribute? 20:13:42 jeblair, my take - the trademark rules already have an "include the entirety of the code" provision 20:13:51 jeblair, we'd just be deferring making any change to that 20:13:57 I'm not worried about mikal and annegentle representing the TC vs. RackSpace on this -- we're going to be discussing our position as a group anyway 20:14:05 jeblair, that was jbryce's way of explaining it too 20:14:09 * russellb happy with mikal and annegentle as reps 20:14:16 markmc: gotcha. 20:14:25 jeblair: I think if we focused on interop for the first cycle, we're really saying that the board can use its discretion on what code must be included and how to enforce that. For example a gentleman's agreement might be sufficient for now. 20:14:31 jeblair: thanks for raising that, I was reaching the same question point 20:14:52 it certainly isn't free reign to "not run our code" 20:15:04 right, which i think is the big thing we probably do have consensus on 20:15:11 so let's just leave it there for now IMO 20:15:12 it just means we wouldn't get any more specific on that ... yet 20:15:48 ok, we've a full agenda and seem to all want to digest the draft 20:15:53 moving on, last chance? 20:15:59 It seems we're cool with Anne and I 20:16:02 So thanks for that 20:16:04 yep 20:16:05 ++ mikal and annegentle 20:16:05 thanks 20:16:08 And move on... 20:16:11 #topic Integrated projects and new requirements: Nova 20:16:11 #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026450.html 20:16:11 #link https://etherpad.openstack.org/p/IcehouseProjectReviewNova 20:16:16 you're up russellb 20:16:18 hi! 20:16:27 take your seat in the dock 20:16:30 or stand, rather 20:16:30 so, I wanted to go through all currently integrated projects and review them using our new criteria 20:16:37 so, Nova up first 20:16:49 the etherpad markmc linked to has the requirements, and my notes for nova on those requirements 20:16:56 i can hit a few discussion points, and then any discussion 20:17:15 on the testing front, we have a lot, but there are a few pain points i think we all want to improve 20:17:24 we lack multi-node testing, so some key things like live migration aren't tested 20:17:40 we also lack respectable test coverage on cells 20:17:56 we've got closing the cells testing gap on the roadmap for Juno 20:18:09 and on multi-node, sounds like there's progress being made there too, coming from the tripleo side of things 20:18:29 the other point i had notes on was bug triage 20:18:32 we haven't been good at it 20:18:46 we've had a few people go through the "bug czar" position without much success 20:18:58 well, the problem with bug triage is arguably a good one - lots of people filing bugs 20:19:03 i've just appointed a new person to that position, tracy jones, who seems very eager to make progress with it 20:19:11 yeah, that's true 20:19:11 It would be good to read those bugs too though 20:19:17 when looking at new projects, we could see how active bug reporters are? 20:19:24 right, i just want to make sure we're catching the important ones 20:19:30 and being responsive to these contributions 20:19:38 yeah, don't get me wrong - agree that better bug triage is important 20:20:03 there are also just straight up challenges with a large bug queue, because there are inherently dupes in it then, especially with how bad launchpad search is 20:20:16 that's true though, maybe looking at some combination of reports and triage of those reports is the right thing 20:20:34 if a new project is getting zero reports ... that would be a concern 20:20:39 I guess the question is if Nova was coming up for graduation review 20:20:40 it's either perfect, or not used 20:20:42 are there any red flags 20:20:47 yeah 20:20:50 are we unfairly giving nova a pass ? 20:20:57 good way to put it 20:21:00 would we expect a greater level of testing? 20:21:01 so the red flag for me is actually cells 20:21:03 I don't think so 20:21:09 not so much because of the lack of testing 20:21:24 we actually heard of some large deployments being interested in it last week, 20:21:24 the 2 ways to deploy nova issue? 20:21:25 but the reason for the lack of testing, which is it really implements a different subset of nova 20:21:27 if that's what you're going to say 20:21:46 so i definitely ACK that it's a problem, and it's not going to stay this way forever 20:21:54 we had a really good discussion on next generation cells last week 20:22:05 that would solve this 20:22:11 assuming it gets done :-) 20:22:14 honestly, the 2 ways to deploy nova is a problem, but the fact that a lot of features just don't work on cells, becomes a problem 20:22:23 yep 20:22:34 so, it's host aggregates (which is a WIP actually) and security groups AFAIK 20:22:48 well, and the total awkwardness of every other project not having the cells concept 20:22:49 sdague, what would our general advice to projects - don't merge WIP features like cells ? 20:23:09 so based on the last tempest results, it's actually much more than that I think 20:23:31 sdague: could be, not supposed to be ... not testing it doesn't help 20:23:50 russellb: agreed, I turned back on a tempest job last week to have some data 20:23:50 "if rackspace uses it, it probably works" isn't a great spot to be in :) 20:23:52 non voting 20:23:55 cool 20:24:03 there are definitely some substantial regressions from havana 20:24:16 markmc: good question though ... what advice would we give nova of the past 20:24:43 I basically think we don't have better ideas for how this should have been done 20:24:46 markmc: so I think cells should have been marked as experimental / unsupported until finished implementing the manager 20:24:53 so 20:24:56 I think we could have asked for more active devs on it 20:24:59 we actually did mark it experimental when it merged 20:25:01 ok, I consider it experimental :) 20:25:05 It was basically one person 20:25:13 and we never really claimed it to be non-experimental 20:25:19 we just don't really have a clear way to communicate that 20:25:30 the original release notes called it experimental though, and we haven't made a statement since 20:25:30 it's off by default, for a start 20:25:36 markmc: +1 20:25:40 well there are tons of warning going in on compute drivers that are considered unsupported 20:25:51 should something equivalent be put in for cells? 20:25:58 I'm fine with that 20:25:59 I think so 20:26:04 sure, that's fine with me 20:26:08 (not that I get a vote here :P) 20:26:11 it's tested, but only lightly 20:26:15 I don't know if that does you much good after somebody deployed it though 20:26:41 Treat it as an extension, leave it disabled and don't put it in mainline docs 20:26:53 sure, so there is definitely a messaging question. 20:26:56 no, but perhaps helps set expectations for people playing with it now 20:26:57 so, cells are documented in the Ops Guide already, NeCTAR has it in their use case 20:27:09 #link http://docs.openstack.org/trunk/openstack-ops/content/scaling.html#segregate_cloud 20:27:12 yeah, it is used successfully by multiple large deployments 20:27:16 it's not junk by any stretch 20:27:28 not really wanting to extricate 20:27:29 just a bit confusing, maintenance burden not so great, etc 20:27:45 ok, let's retreat from the cells rabbit hole 20:27:49 good feedback though 20:27:57 anything else on nova? 20:28:06 another thought - reviewer team efficacy 20:28:07 annegentle: I don't think we'd remove it from the docs, but mark it as experimental there? 20:28:15 it's a problem with nova right now 20:28:19 markmc: good point 20:28:23 (says he as one of the least active reviewers right now) 20:28:31 not just having a diverse review team, but one that keeps up? 20:28:32 should it be on the graduation review checklist? 20:28:50 #link http://russellbryant.net/openstack-stats/nova-openreviews.txt 20:28:50 it's a pain point for us for sure 20:28:56 --> Total Open Reviews: 511 20:28:56 --> Waiting on Submitter: 127 20:28:56 --> Waiting on Reviewer: 384 20:29:17 * russellb wishes he had a good answer for that 20:29:19 russellb: do you track the review stats for reviews for approved blueprints and bugs separately from all the rest? I'd be curious to know how well you keep up with what you promise to do. 20:29:29 dhellmann: no, good idea though 20:29:40 though we generally approve everything that's sane 20:29:48 we don't have a gate for "agree to do it" right now 20:29:55 we tried that with the core sponsors for blueprints idea 20:30:00 which was a complete failure 20:30:06 because nobody sponsored anything 20:30:18 that would make for thin release notes, with no changes ;-) 20:30:20 (nobody wanted to spend extra time messing around in launchpad i guess, i don't know) 20:30:39 russellb: I think we were all too busy... 20:30:43 dhellmann: or something robust 20:30:44 markmc: so it's a good question, but I actually think one that's almost of a different nature, which is challenges of maturing projects in OpenStack that have way more inbound then review bandwidth 20:30:52 that's good to know, though, I was thinking of something like that for oslo but maybe I'll look for other options 20:30:54 so on this note ... should also compare to the overall stats http://russellbryant.net/openstack-stats/all-openreviews.txt 20:31:03 which I think is honestly typically the inverse of what we see on projects in early stage 20:31:04 the wait times for nova are in line with the openstack-wide average 20:31:09 so maybe that's the way to look at it ... 20:31:12 sdague: good point 20:31:23 your review queue shouldn't be painfully worse than openstack overall 20:31:24 or something 20:31:59 ok, any other thoughts on nova? 20:32:05 for a new project to have a review queue that bad, it would have to mean they aren't collaborating with non-cores or something, right? 20:32:13 i think we should keep nova. :) 20:32:18 jeblair: yay! 20:32:21 jeblair: yes! 20:32:26 <3 20:32:28 jeblair: only if russellb makes us cookies :) 20:32:31 jeblair, until something better comes along :) 20:32:36 markmc: +1 20:32:39 heh 20:32:42 ok, thanks russellb 20:32:45 * markmc moves along 20:32:46 #topic Creating key distribution service (KDS) under identity program 20:32:46 #link https://review.openstack.org/73022 20:32:50 dolphm, this is yours ? 20:33:09 markmc: yes 20:33:25 dolphm, want to talk us through it ? 20:33:37 so, if it's a server project, shouldn't it apply for incubation? or what am i missing? 20:33:46 i actually didn't realize it was on the TC agenda today - can it be deferred til next week? 20:33:53 is it a user facing API ? 20:34:00 dolphm, ok, quick first thoughts to those questions ? 20:34:02 markmc: yes 20:34:18 dolphm, where user == operator ? or self-service user ? 20:34:19 russellb: it's already landing in keystone's codebase, as a discrete service 20:34:24 russellb: keystone.contrib.kds 20:34:45 dolphm: I think the question there was about listing it as "integrated" vs. "other" at this stage 20:34:45 it has it's own API, with an eye toward splitting the codebase into it's own repo before shipping icehouse 20:35:01 dhellmann: ah; i don't have a preference between the two 20:35:12 patchset 1 against governance has it as 'other', actually 20:35:23 i changed it to 'integrated' considering it's already in a core project atm 20:35:29 integrated* project 20:35:34 so, i don't think quickly passing through the keystone tree before going into its own repo is a good reason to skip the incubation process 20:35:40 agreed 20:35:45 sounds like shenanigans IMO 20:35:46 sounds like bypassing this whole process? 20:36:15 is it a widening of keystone's scope that deserved TC review in the first place ? 20:36:19 we followed the incubation process on things like cinder, ironic, and gantt, so I think if it's trying to split out it should follow the same process 20:36:26 or did we do that already ? 20:36:29 markmc: I think it is a widening of scope, yes 20:36:45 russellb: jgriffith: i don't disagree 20:36:46 and i don't think we've discussed it in the TC ... 20:37:06 ok, dolphm requested we defer until next week 20:37:06 The only discussion I recall is the brief proposal on ML 20:37:10 which is fair enough 20:37:13 works for me 20:37:14 russellb: we talked about it in context of barbican's application iirc 20:37:15 cool 20:37:16 let's stew on it for another week? 20:37:20 fair 20:37:21 markmc: sure 20:37:24 cool 20:37:26 moving along 20:37:33 #topic Topics you'd like to see discussed at joint Board/TC meeting in Atlanta 20:37:33 annegentle: ++ 20:37:33 #link http://lists.openstack.org/pipermail/openstack-tc/2014-February/000536.html 20:37:43 now, it's only a 2 hour meeting 20:37:46 i'll bring cookies 20:37:51 (maybe) 20:37:51 with roughly 40 attendees 20:37:56 mm baked goods 20:38:02 so, I'd say max 2/3 topics total 20:38:11 up to 40 attendees 20:38:15 defcore i suppose. 20:38:19 what do our constituents want discussed? 20:38:25 but I'm sure AlanClark and ttx have discussed already 20:38:33 though surely there's other worth topics 20:38:35 let's just throw out some ideas 20:38:35 diversity 20:38:45 how the board and tc should engage with each other 20:38:49 jeblair: +1 20:38:50 annegentle: +1 20:38:54 two good ones 20:38:57 That should be item one 20:39:01 getting users more engaged with dev, though I dunno if thats a board topic 20:39:02 Everything else flows from that one 20:39:05 jeblair: +1 20:39:14 * markmc would like to think he'd be prepared to introduce the "do we really need this CLA?" topic 20:39:19 ideally ways we can engage without have to do face to face to make any progress 20:39:23 markmc: +1 20:39:30 russellb: +1000 20:39:36 Should we do a brain storm on an etherpad? 20:39:41 mikal, go for it! 20:39:42 russellb: +1 20:39:43 markmc: ++ 20:39:43 russellb: I like that topic as well, plus it's ironic at an in-person meeting :) 20:40:27 tick, tock, mikal's creating an etherpad 20:40:31 https://etherpad.openstack.org/p/juno-tc-board-meeting-ideas 20:41:17 so I guess the question is what of these topics do we think only make good progress if the TC is there. I can see how the collaboration one would. 20:41:18 dangit 20:41:24 too many people trying to edit the same lines 20:41:25 LOL 20:41:28 That etherpad is awesome 20:41:32 do we actually need the TC for the CLA one? 20:41:34 Perhaps we should let that stew for a week too? 20:41:41 sdague: the TC can push it? 20:41:50 mikal: should we? 20:41:51 not that I don't think the CLA one is important, just trying to conserve the window 20:42:05 so what's the problem with CLA? Just curious? 20:42:10 I think this etherpad is a grab bag of ideas 20:42:10 hmm, any foundation resources we may want to request? 20:42:12 the infra team has serious issues with the cla 20:42:13 We should list everythign 20:42:14 to help support development? 20:42:18 Then we can pick the top two or three 20:42:22 russellb: that's a good one 20:42:29 i don't have specifics in mind off hand 20:42:31 but seems appropriate 20:42:32 russellb: getting rid of CLA helps dev? 20:42:35 if it would help, we can write up our thoughts about it for the tc 20:42:36 jgriffith: indeed :) 20:42:45 russellb: hmm... careful what you wish for 20:42:49 jgriffith: we have at least one contribution from a US govt employee that can't land because he can't sign it 20:42:54 russellb: I think you'll have unexpected results 20:42:59 dhellmann: I see 20:43:04 interesting 20:43:10 jgriffith, russellb: yes, the really short version is that it's a process and technical burden to administer, hinders new contributors, and has no real benefit 20:43:14 an exception process may be more appropriate IMO 20:43:17 jgriffith: something to do with patent assignementsz 20:43:20 but I know we're not here to discuss this :) 20:43:20 jgriffith: i mean like specific asks ... budget we can tap into for cloud resources if we want above and beyond what is donated 20:43:41 russellb: oh... different topic 20:43:47 so the other question is about voting on board things 20:44:16 lifeless: what do you mean by "users" 20:44:18 sdague, voting on board things? 20:44:20 which I know was punted, but changing the board election process for individual representatives to be more like the tc is something I'd like to continue to see pushed 20:44:37 vishy: operators 20:44:43 vishy: public and private 20:44:44 not necessarily a TC+board thing, but +1 that i don't like the current individual director election system 20:44:49 sdague, IMHO, the TC doesn't really have much of a place in that debate - disagree ? 20:44:52 ok so that is what the users group is for 20:44:56 sdague, as a body, for sure as individuals 20:45:20 markmc: I think I agree, just throwing out other specific topics of interest. 20:45:20 that tim bell leads 20:45:28 sdague, yep, cool 20:45:49 sdague: ah yes. i think it was determined that the turnout would not have supported an ammendment; we should be able to cull the membership list for the next board election, i think? 20:45:59 sdague, russellb, how about "Brief feedback from technical community on the individual director election process" ? 20:46:05 markmc: SURE 20:46:07 err, sure. 20:46:10 jeblair: that was my understanding, too 20:46:25 russellb, WHAT? 20:46:31 * markmc cocks his ear 20:46:41 jeblair: right, I guess that's the meta issue, which is the fact that current foundation rules on individual members basically make bylaw changes impossible 20:47:01 because we'll never get quorum 20:47:11 which does affect the TC 20:47:25 sdague: yep. and we've already mentioned two things that would require bylaws changes just in this 5 mins of brainstorming. 20:47:48 sdague, added "Similarly - technical communities desire to not have bylaws changes held up by quorum requirement with huge membership" 20:47:49 do we need to discuss project naming rules/process? 20:48:01 markmc: +1, thanks 20:48:03 ah, indeed 20:48:03 seems there's some conflict there, or perhaps misunderstanding 20:48:25 that might take the whole meeting 20:48:39 Wow... better schedule a few more days :) 20:48:40 2 hours enough? :) 20:48:40 russellb, this: https://github.com/openstack/governance/blob/master/resolutions/20131106-ceilometer-and-heat-official-names 20:48:59 ok, let's move it along 20:49:04 lots of ideas :) 20:49:04 what no one suggested trust falls? 20:49:09 annegentle: lol! 20:49:14 annegentle: ha! 20:49:14 #topic Minor governance changes 20:49:24 pull yourselves together 20:49:27 plz to be +1ing my deprecated code thingy! 20:49:32 Add a requirement for deprecating duplicated code: https://review.openstack.org/70389 20:49:49 that looks ready for ttx to approve 20:49:57 Add missed mission statement for Data Processing: https://review.openstack.org/71045 20:50:18 who else needs shaming for lack of mission statement 20:50:29 i do 20:50:40 markmcclain: ! 20:50:42 jeblair: shame on you sir 20:50:44 one more: Add oslo.test to the Oslo program: https://review.openstack.org/#/c/74117/ 20:50:45 mikal: thank you 20:50:50 jeblair: you're welcome 20:50:56 jgriffith: and you! 20:51:01 * markmc chuckles 20:51:02 thank you sir may I have another.... 20:51:03 mission statement coming with our project review 20:51:11 dhellmann: do you want to do the name change first? 20:51:12 markmcclain: excellent 20:51:14 russellb, nice high horse you've got there 20:51:16 :) 20:51:22 russellb, making a dash for the moral high ground on it ? 20:51:25 markmc: only because i got mine in like a month ago 20:51:28 heh 20:51:31 sdague: I was going to wait to change the repo name after the i-3 cutoff, assuming we don't want gerrit downtime 20:51:33 now i can give crap to others 20:51:40 * russellb gets knocked off his horse by markmc 20:51:40 dhellmann: ok 20:51:41 sorry sir 20:51:46 i'll hush now 20:51:51 well, we can't put it into the gate until the name change, right? 20:51:55 last one ... 20:51:56 Add storyboard-webclient to the infra program: https://review.openstack.org/72706 20:52:12 jeblair, needs you 20:52:14 sdague: ? 20:52:20 done 20:52:21 Do we think storyboard should have gone through an incubation approval like process? 20:52:30 cool 20:52:35 dhellmann: because of the same issues as olso.sphinx 20:52:45 I get a lot of questions about why we're doing it 20:52:47 mikal: it's a component project of the infrastructure program, not targeting the integrated release 20:52:48 sdague: I'm changing the name of the package now, and the git repo later 20:52:49 mikal, well, it's not intended to be integrated 20:52:53 It might be nice to be able to answer those in public once and for all 20:52:55 dhellmann: ah ok 20:52:59 mikal, now would be a good time to raise the questions 20:53:01 mikal: jeblair: it's similar to kite/keystone tho 20:53:09 annegentle: how? 20:53:11 mikal, consider this the approval process :) 20:53:13 it's not a part of openstack though 20:53:14 totally logical but should be discussed 20:53:23 that's the key difference 20:53:24 jeblair: yeah, I don't intend to block it 20:53:34 I think we could do better at explaining what it is to the community though 20:53:35 jeblair: just a discussion to have 20:53:45 mikal, e.g. you could -1 saying you want a discussion on openstack-dev 20:53:50 mikal, which would be totally fair 20:53:52 storyboard is the answer to everything 20:54:08 It seems odd to do that for the webclient when the main thing got a pass 20:54:11 But sure 20:54:13 storyboard has been discussed widely on openstack-dev already... 20:54:15 russellb: well storyboard and tripleo-gate :) 20:54:18 heh 20:54:29 jeblair: this is news to me 20:54:34 jeblair: but not with a program owner that I know of 20:54:34 jeblair: I stand possibly corrected 20:54:37 sdague: and both exist :) 20:54:38 * mikal shall search after the meeting 20:54:45 jeblair, maybe add a link to the review? if you have it handy 20:54:55 ok, 5 minutes left 20:54:56 we've never asserted that new projects need to go through approval 20:55:05 #topic Open discussion 20:55:11 jeblair: but we just did that to dolphm right? 20:55:14 yeh, realistically infra starts about 6 - 10 new projects a cycle 20:55:19 annegentle: that was for an *integrated* project 20:55:19 to support the project 20:55:23 annegentle: but that's a part of openstack itself, part of the integrated release 20:55:29 jeblair, so you don't think the TC needs to vote on adding a new project to a program ? 20:55:32 annegentle: new _integrated_ projects go through approval and review 20:55:35 dhellmann: Identity is aprogram 20:55:41 a space program! 20:55:42 jeblair, raises the question why we're voting on this review, no ? 20:55:46 markmc: I definitely don't :) 20:55:46 markmc: no i don't 20:55:51 annegentle: programs aren't integrated, projects are 20:56:00 I don't think we should vote projects that exist to solve internal needs 20:56:02 good point ... is this review just housekeeping, or do we get to have a discussion? 20:56:02 markmc: i don't think we should vote on it; i think it's a non-material update and the chair should approve it 20:56:14 jeblair: that's how i feel 20:56:25 jeblair, ok, sounds like a job for real_ttx to deliberate over 20:56:25 same with the oslo updates recently 20:56:33 fake_ttx sucks at such things 20:56:36 jeblair: I'm fine with that but I'm trying to understand the program/project yaml updates that would happen then 20:56:42 several other programs have projects that have been created without review too, because they don't affect the integrated release... 20:56:45 fake_ttx has done an excellent job chairing today :-) 20:56:46 jeblair, that said, discussion is good 20:56:56 jeblair, but we should be clear where the TC has veto rights, for sure 20:57:10 markmc: sure, i'm happy to talk about why we're doing storyboard and why we think we need it 20:57:10 jeblair: and I'm good with that, adding repos as needed, of course 20:57:18 markmc: i'm a little less happy with "-1 so we can talk about it" 20:57:22 jeblair, so as to not give TC members an overly large sense of their own importance :) 20:57:32 jeblair, cool, point taken 20:57:39 jeblair: and I don't have another program in mind for storyboard, just wanting to understand the program/project yaml and how to review changes to it 20:58:06 yeh, maybe it's just a question of whether the contents of the the "other" chunk is even interesting in this file. Or why we update it there. 20:58:07 jeblair, that said - actually switching over to using it for all projects would be a TC thing, I guess 20:58:13 i think it's a hosuekeeping, ttx approves right away kind of thing, unless it's something that should be going through incubation 20:58:21 am I making any sense? (about how to review the program/project changes?) 20:58:24 as ttx explained it, the point of the list is to figure out who has atc in which programs for ptl elections, so I think it's reasonable to give a quick review to new items on the list -- even non-integrated projects 20:58:47 russellb: ah housekeeping makes sense, then we don't have to review as closely/slowly 20:58:47 waiting for the tc to vote on oslo changes hasn't held us up 20:59:11 markmc: we definetely wouldn't do that without talking to the tc. :) we do plan to switch infra to start dog-fooding it asap. 20:59:11 I think we're out of time now 20:59:11 russellb: I disagree for adding new items, but renames should be considered housekeeping 20:59:33 unless the rename is out of stackforge into a program, I guess 21:00:06 jeblair, coolness 21:00:06 dhellmann: I don't see why the TC should approve what projects in a program grant atc to the program 21:00:12 dhellmann: isn't that a program responsibility ? 21:00:16 ok, we're out of time 21:00:34 #endmeeting