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