20:01:22 <ttx> #startmeeting tc
20:01:22 <openstack> Meeting started Tue Apr  5 20:01:22 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:25 <openstack> The meeting name has been set to 'tc'
20:01:28 <dtroyer_zz> o/
20:01:32 <piet> o/
20:01:35 <jaypipes> o/
20:01:38 <ttx> Hello, dear members of the mitaka Technical Committee and visitors
20:01:43 <ttx> This is the agenda for our last meeting:
20:01:47 <mestery> ttx waxing poetic :)
20:01:51 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:53 <lifeless> ttx: /o\
20:02:06 <ttx> First a bit of boring administrativia
20:02:11 <ttx> #topic Update Newton new PTL's
20:02:12 <amrith> hello dear ttx :)
20:02:17 <ttx> #link https://review.openstack.org/298228
20:02:27 <ttx> There were a few back-and-forth on email addresses, I think it's good to go now
20:02:37 <ttx> could use a couple more votes
20:02:54 <ttx> We'll update Renat's address in a separate change
20:03:03 <flaper87> ship it!
20:03:10 <flaper87> I can do that while we get votes
20:03:13 <ttx> #action ttx to update Renat's address if nobody beats him to it
20:03:19 * devananda lurks
20:03:25 <flaper87> or you do it
20:03:28 <flaper87> :P
20:03:29 <ttx> Alright it is in
20:03:46 <ttx> #topic Mention in project requirements about ptl election
20:03:54 <ttx> #link https://review.openstack.org/295609
20:04:05 <ttx> We discussed this one last week
20:04:15 <thingee> o/
20:04:20 <ttx> just got enough votes, so I can approve that one too
20:04:52 <ttx> #topic Change mission statement by recent change
20:04:58 <ttx> #link https://review.openstack.org/292610
20:05:05 <ttx> This one bakes the new mission statement in our charter.
20:05:14 <lifeless> yay :)
20:05:14 <ttx> As for other charter changes, it's a special motion which requires 2/3 votes in favor
20:05:21 <ttx> So we are short of a few votes here
20:05:31 <flaper87> ttx: https://review.openstack.org/#/c/301890/
20:05:33 <ttx> no longer
20:05:50 <ttx> flaper87: will approve that one as typo change
20:05:56 <ttx> once it passes tests
20:05:59 <ttx> thx
20:06:00 <flaper87> sounds good
20:06:02 <flaper87> np
20:06:09 * flaper87 happy with the new mission statement
20:06:18 <ttx> alright approved
20:06:25 <mestery> Excellent!
20:06:27 <ttx> Good to have brought that to conclusion
20:06:29 <flaper87> YAY!
20:06:37 * dims sneaks in
20:06:44 <ttx> #topic Retire the kite/python-kiteclient projects
20:06:56 <ttx> #link https://review.openstack.org/297803
20:07:00 <annegentle> ahh, retirement
20:07:03 <ttx> This one is also a no-brainer. With the PTL approving it, we actually don't really need a formal vote on that one
20:07:06 <annegentle> what a lovely word
20:07:10 <mestery> annegentle: I know, right?
20:07:12 <ttx> So I'll merge this one now unless someone objects.
20:07:18 <mestery> ttx: merge away!
20:07:25 <flaper87> ship it
20:07:34 <ttx> LESS projects!
20:07:40 <edleafe> go fly a kite!
20:07:42 <mestery> less is the new more
20:07:46 <sdague> flaper87: well... scuttle it
20:07:47 <ttx> we should probably have cleaned that one up a bit earlier :)
20:07:55 <jeblair> did the project git a readme update?
20:07:58 <ttx> Alright. Now more interesting topics
20:08:03 <flaper87> sdague: indeed, that's more appropriate
20:08:20 <ttx> jeblair: it's just made unofficial, the repo is not attic-ed yet
20:08:22 <annegentle> mestery: heh
20:08:28 <sdague> jeblair: it does not seem to have - https://github.com/openstack/kite
20:08:35 <sdague> though it should be moved to the attic too I think
20:08:42 <jeblair> ttx: right, but maybe this is a good checkpoint to make sure that it gets cleaned up
20:08:57 <ttx> one never knows maybe it will get a new life outside :)
20:08:59 <sdague> it has had 3 commits since Jan 1 2015 - https://github.com/openstack/kite/commits/master
20:09:01 <jeblair> we have a section on this: http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
20:09:15 <ttx> sdague: that's still more than all the packaging-deb repos combined
20:09:32 <jeblair> i'm not suggesting we hold off on approving this change
20:09:40 <jeblair> which is good, since it was just approved
20:09:58 <ttx> jeblair: we could volunteer someone to properly follow-up with repo decommission
20:10:01 <jeblair> but maybe we could incorprate a checkpoint of "please do the steps in the infra manual" for this
20:10:09 <anteaya> jeblair: 297719 297741
20:10:29 <jeblair> anteaya: awesome!
20:10:33 <anteaya> :)
20:10:39 <sdague> yeh, I think the biggest issue is getting someone that can approve those to pay attention
20:10:40 <ttx> ah! anteaya wins gerrit search award
20:10:53 <anteaya> thank you
20:11:00 <annegentle> nice one anteaya
20:11:01 <ttx> moving on ?
20:11:04 <jeblair> i think the infra team probably doesn't mind stepping in these cases if we have to
20:11:08 <anteaya> annegentle: :)
20:11:15 <jeblair> just the more other folks do it the better :)
20:11:28 <sdague> well I'm throwing my +1 on both of those for support
20:11:35 <jeblair> i will leave a comment on the governance changes pointing to those for reference
20:11:37 <annegentle> jeblair: yeah, let someone test the docs for decommission :)
20:11:41 <ttx> #topic Separating cross-project specs and guidelines
20:11:53 <ttx> thingee: care to introduce the topic ?
20:11:56 <thingee> o/
20:11:58 <lifeless> now the actual meeting bit :)
20:12:08 <ttx> lifeless: yep, with plenty of time to spare
20:12:38 <thingee> so in previous discussions within the cross-project team there seemed to be confusion with specifications.
20:12:54 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090156.html
20:12:59 <ttx> #link https://review.openstack.org/#/c/296571/
20:13:04 <thingee> this first started with the product working group introducing a spec that seemed more like a wish list for rolling upgrades.
20:13:45 <thingee> we later agreed that we can't have a spec for rolling upgrades. You can share ideas of how to go about solving some problems in the area, but it is not applicable to all projects.
20:13:55 <thingee> dansmith: am I on track so far ^ ?
20:13:58 <ttx> I think we need to somehow separate things that have a start and an end, from things that are more living documents
20:14:35 <thingee> so this is formally recognizing those guidelines (which already exist) and the specs being separate things.
20:14:41 <flaper87> I wonder if something like project team guide but for cross-project guidelines would work for this
20:14:46 <ttx> I was thinking specs = finite efforts to reach a goal, and guidelines = living design doc
20:14:53 <dansmith> ttx: +1
20:15:02 <dansmith> I don't want specs for anything other than actual work to be done
20:15:14 <dansmith> and even then, sparingly
20:15:19 <ttx> can be same repo or different repo, same approval rules or different approval rules, but step 1 is to recognize the difference
20:15:38 <flaper87> I wouldn't have it in the same repo
20:15:39 <sdague> we should also figure out why we are creating any of these artifacts at all. Because my understanding with doing cross project specs was to provide a structured way to discuss a hard problem in detail to come up with a solution that would then make reviewing code for that solution easier
20:15:46 <thingee> so this is a first attempt. thanks to sdague for weighing in, otherwise, not too much feedback unfortunately.
20:15:50 <sdague> because there was a reference document
20:15:53 <flaper87> as far as the approval rules go, I think it's fine to let that to the cross-project repo chair
20:16:20 <sdague> and I think we should make sure than any artifacts we are building are actually helping us do something
20:16:46 <shamail> thingee: would both specs and guidelines still need TC approval after separation?
20:16:52 <annegentle> guidelines are great to have
20:17:00 <devananda> sometimes there is an overlap between proscribing how to do a thing generally and designing how to solve a thing specifically
20:17:09 <ttx> sdague: so my take on cross-project specs is that they are goals that affect more than one team and the cross-project spec repo is a neutral place to get consensus across teams boudaries
20:17:20 <thingee> sdague: I think that's a later problem, but do recognize it as a problem. I have not really spent time, but I don't see how serious the community takes cross-project specs to begin with.
20:17:37 <carolbarrett> The intent behind the rolling upgrades cross-project spec proposal was to provide input on user requirements for upgrading openstack as a basis for defining project specific specs and blueprints.
20:17:39 <ttx> with guidelines informing the design of everything, cross-project or not
20:17:46 <devananda> ttx: +1
20:17:48 <thingee> Kind of goes with the api-wg. In previous TC discussions, a tag of following guidelines would be granted as an incentive
20:17:53 <sdague> so, lets take cross project spec #1 - which is the logging guidelines
20:17:59 <sdague> as a concrete example
20:18:02 <dansmith> carolbarrett: but we did that with the user story thing
20:18:04 <lifeless> +1 sdague
20:18:20 <sdague> that was used to get some convergence on logging patterns between projects
20:18:32 <sdague> and provide a reference for people going and fixing those in projects
20:18:34 <ttx> sdague: I think it should have been two things. Guidelines, and then a spec to catch up existing projects to the expected level
20:18:46 <carolbarrett> dansmith: The user story doesn't provide an implementation methodology across projects, that's what we were hoping to achieve for upgrades
20:19:03 <thingee> two conversations going on..
20:19:08 <dansmith> carolbarrett: right, but it also including things we weren't going to do because the authors wanted it reflected in there
20:19:14 <jeblair> ttx: in that case is the spec more than "implement the guidelines?"
20:19:25 <dansmith> carolbarrett: so, we can't really have an implementation plan for something we're not going to do :)
20:19:30 <sdague> ttx: and for something like logging, it's kind of a constant battle
20:19:44 <ttx> jeblair: it lists assignees and projects too
20:20:00 <thingee> sdague: so if it's on-going, then you can't have a spec. you have a guideline.
20:20:00 <ttx> sdague: so maybe there is no catch-up spec because it's more of a continuous process
20:20:14 <sdague> ttx: it assumes that it's a DONE able activity, my experience is it just hasn't been
20:20:34 <ttx> sdague: yeah, maybe the spec #1 example is a corner case
20:20:41 <sdague> ok, well regardless for what it's called, it was an artifact that did help a set of people make progress in a lot of places
20:20:46 <annegentle> I think the guidelines would be useful beyond just for contributor teams.
20:20:47 <ttx> Ideally all specs should be completable
20:20:49 <sdague> even if there remains work to be done
20:21:00 <annegentle> specs should contain tasks.
20:21:18 <flaper87> Wonder if this cross-project guidelines could host guidelines from other working groups
20:21:21 <carolbarrett> dansmith: through feedback we refine and reach an agreement on what's needed versus what the community will do. But we still need the spec for projects to gain that info...for future big tent projects too
20:21:51 <edleafe> I think this is a vocabulary issue
20:21:55 <flaper87> Rather than having separate docs and guidelines for every working group
20:22:02 <ttx> I think retrofitting guidelines into teh spec repo kind of discouraged us to create more of them
20:22:05 <cdent> Much of this use of gerrit to have discussion to reach consensus on how to do stuff seems to stem from fear of email.
20:22:07 <edleafe> 'spec' means something specific, at least in Nova
20:22:38 <sdague> cdent: that's actually probably true. Though gerrit make it easier to see when things are converging
20:23:00 <ttx> so, anyone disagreeing that specs and guidelines are fundamentally different ?
20:23:30 <anteaya> I am not disagreeing
20:23:43 <annegentle> ttx: the only additional difficulty is that some teams may have different definition for specs
20:23:44 <sdague> I feel like there is enough grey space I'm not sure it's worth the distinction
20:23:50 <sdague> but that might just be me
20:23:55 <annegentle> for example, keystone documents concepts of their REST API in their specs repo
20:23:59 <cdent> I think the debate is over which is more useful.
20:24:05 <annegentle> I think I'll need to encourage that to stop, but it's another case
20:24:07 <devananda> ttx: I agree that they are different
20:24:09 * flaper87 agrees they are different
20:24:13 <annegentle> of team-to-team disparity
20:24:15 <carolbarrett> Seems like its around level of detail...
20:24:26 <thingee> sdague: so going back to the original problem. If someone felt they could write a spec on best practices for rolling upgrades, could it go in openstack-specs?
20:24:26 <sdague> creating artifacts that help us solve a concrete thing is mostly my concern
20:24:28 <ttx> sdague: that is fair.... I can totally see grey things. If everything is grey there, then we just produce a gradient of docs
20:24:40 <devananda> as an example of a finite unit of work that requires three projects: nova/ironic/neutron network integration
20:25:07 <ttx> but I'd argue most things are either white or black, not corner cases
20:25:27 <devananda> but I haven't seen anything yet in the cross project specs that stands out as affecting all projects AND being finite. that seems counter-intuitive when we have a growing tent ...
20:25:59 <thingee> devananda: deprecating clis in favor of osc
20:26:00 <jeblair> devananda: that's a good observation
20:26:11 <sdague> devananda: right, which is part of the grey space. The closest thing to that was the CORS work.
20:26:14 <lifeless> ttx: I agree that the underlying concepts are different between 'guidance' and 'instruction'
20:26:18 <edleafe> "Guideline" says "here is what you should be doing". "Spec" says "here is the specific way we are going to do it".
20:26:42 <dtroyer_zz> strategy vs tactics
20:26:42 <cdent> spec, as edleafe is describing it, requires mandate
20:26:47 <lifeless> ttx: but I think pragmatically - if they are both binding, and both consensus built, I don't understand the value in splitting them up
20:26:53 <edleafe> dtroyer_zz: +1
20:26:54 <devananda> thingee: fair point. I'd agree that is finite, if it also mandated that no new projects create new CLIs
20:27:01 <carolbarrett> don't guidelines lead to specs?
20:27:13 <sdague> carolbarrett: not really
20:27:18 <ttx> edleafe: arguably in the logging guidelines case, you don't need a cross-project spec. You just need per-project specs (or even just a bug with an assignee)
20:27:26 <dansmith> carolbarrett: not IMHO
20:27:35 <ttx> since there is not so much value in tracking the coordination
20:27:41 <devananda> lifeless: I believe the difference is that a spec is written, at least currently, in such a way as to define an end-state
20:27:42 <flaper87> carolbarrett: it could even be the other way around
20:27:48 <lifeless> ttx: its like the whole overly-modelled split between 'bug' and 'blueprint' in Launchpad - that was actively harmful there, and I'm worried we're going down the same path here
20:27:53 <edleafe> ttx: true. In the case of logging, it probably doesn't need a spec
20:28:01 <edleafe> flaper87: ??
20:28:07 <sdague> lifeless: ++
20:28:10 <ttx> carolbarrett: a guideline could just trigger per-project specs or bugs, not necessarily a cross-project one
20:28:14 <flaper87> edleafe: ?
20:28:21 <lifeless> devananda: dansmith has said specs reflect specific work to do, as being the key thing
20:28:28 <carolbarrett> sdague: if you outline a task an operator wants to accomplish (guideline) then a spec would detail how that would be achieved in openstack. Is there another approach to this you would want to see used?
20:28:39 <edleafe> flaper87: guideline dependent on a spec?
20:28:43 <sdague> lets me less focused on buckets and more focused on what things would actually help us make specific improvements in openstack
20:28:47 <dtroyer_zz> the cross-project specs seem most useful in catching up existing projects, not so much for new work
20:28:49 <ttx> lifeless/sdague: maybe we should go back to the original problem thingee set out to solve
20:28:55 <lifeless> devananda: a guideline about how things must be done is still an end-state, but its not specific work, and its never 'finished to be forgotten'
20:28:55 <carolbarrett> ttx: true, they may not always be cross project, but I don't think that's the case with rolling upgrades
20:29:23 <sdague> ttx: sure
20:29:28 <flaper87> edleafe: not dependent... The message said "leading" and I can see how after implementing a spec we could come up with new guidelines
20:29:36 <ttx> thingee: what's wrong with the current fuzzy model ?
20:30:01 <ttx> (timeboxing that to 10 more minutes, after that we have more topic to cover)
20:30:03 * thingee finds to copy and paste his last message to sdague
20:30:06 <edleafe> flaper87: ah, ok
20:30:23 <dtroyer_zz> it seems like we need (wait for it) tags to signal some attributes of these docs, then leave them lumped together
20:30:31 <thingee> sdague: so going back to the original problem. If someone felt they could write a spec on best practices for rolling upgrades, could it go in openstack-specs
20:30:55 <lifeless> dtroyer_zz: the tagpocalypse is imminent
20:30:58 <annegentle> thingee: why not the docs?
20:30:58 <sdague> thingee: if it was actually going to be useful in making concrete changes in openstack, sure
20:31:07 <sdague> but the actual artifact in question was not
20:31:21 <sdague> and worse, it was actually definitively wrong in many places
20:31:25 <flaper87> well, but we would endup separating those in-tree anyway, right?
20:31:27 <carolbarrett> annegentle: the capabilities don't exist to be documented...
20:31:29 <thingee> sdague: for the millionth time, I agree and that's what I've been arguing for. :)
20:31:30 <gordc> thingee:can we amend the best practice file(s) when we want?
20:31:34 <flaper87> Like a folder for guidelines and one for actual specs
20:31:39 <lifeless> flaper87: would we? we haven't so far
20:31:45 <ttx> sdague: so it's not guidelines vs. spec, it's how realistic and informed the doc ends up being ?
20:31:58 <flaper87> lifeless: we haven't but we're kinda acknowledging the distinction now
20:32:11 <sdague> ttx: right, it's "is this artifact useful in making a concrete change in openstack"
20:32:13 <mordred> o/
20:32:19 <lifeless> flaper87: well, maybe? I haven't seen an actual problem ascribed to the putative difference so far
20:32:20 <annegentle> carolbarrett: ok then specs are needed if the best practices capability won't actually work in a particular project
20:32:22 <flaper87> and wondering whether that would go in or not is an proof of the distinction between those
20:32:23 <sdague> that's where I've tried to push this line
20:32:31 <gordc> thingee: i'm imagining something like 'this is how we did it in project a, this is how we did in project b, etc..., project c, see what works best'
20:32:35 <carolbarrett> annegentle: +1
20:32:37 <annegentle> sdague: so for the service catalog, we had a nova owner right?
20:32:46 <sdague> most of what's up in openstack-specs aren't right now
20:32:47 <thingee> so kencjohnston and carolbarrett someone needs to come in with actual technical information in the spec that follows what the community is *currently* doing.
20:32:51 <annegentle> sdague: so while we were describing what we wanted, we had workers for tasks
20:33:00 <ttx> sdague: ok then maybe the process works as designed
20:33:11 <dansmith> thingee: and only things that actually apply to everyone
20:33:13 <lifeless> what I'd like to ask
20:33:17 <dansmith> thingee: like logging and api stuff
20:33:21 <lifeless> what do we want to happen differently
20:33:23 <thingee> dansmith: yes of course
20:33:32 <sdague> annegentle: right, we had owners invested in projects that were using this to make sure their work in a couple of projects (nova / keystone) would be constructive, and move the whole openstack ball forward
20:33:41 <lifeless> at a conceptual level: not execution
20:33:42 <thingee> ttx: I'm done, thank you
20:34:03 <thingee> I will abandon the change and feel free to reference this discussion if the spec has issues after meeting the necessary requirements.
20:34:10 <annegentle> sdague: and I know the loss of an ether pad sorta delayed filling in all the technical details but we had the tasks
20:34:27 <carolbarrett> thingee: Thought the cross-project spec process was the approach to developing this...will take back to product wg and come up with another plan.
20:34:30 <annegentle> carolbarrett: I hesitate to put the service catalog up as an example since it's not great though :)
20:34:33 <sdague> annegentle: right, we had to compromise on details in the spec to set certain boundaries
20:35:09 <sdague> but I feel like in that case it was useful concrete artifact to move that ball forward, and be able to reference that bit when working in projects that this was our direction
20:35:34 * dansmith starts taking a drink every time sdague says "artifact"
20:35:36 <thingee> carolbarrett: well someone in the cross-project team could volunteer to help the product working group. Just so far, people that do have knowledge in the rolling upgrade area are very busy people.
20:35:49 <ttx> ok, looks like the anti-overclassification front won this one
20:36:13 <lifeless> ttx: we prefer to be called the peoples front of generality
20:36:23 <dansmith> lifeless: nice
20:36:28 <flaper87> lifeless: lol
20:36:32 <sdague> lifeless: ++
20:36:49 <ttx> OK, next topic then
20:36:57 <ttx> #topic add warning to release:independent
20:37:02 <ttx> #link https://review.openstack.org/299309
20:37:15 <cdent> ("front" is very specific, perhaps "side")
20:37:19 <ttx> I'll do my best impersonation of dhellmann for this one
20:37:35 <ttx> Despite warnings, we had more than one project team realizing one week before Mitaka release that picking up an "independent" release model meant that they would not get listed in the "Mitaka" release page
20:37:44 <ttx> Warnings including http://lists.openstack.org/pipermail/openstack-dev/2016-January/083726.html
20:37:56 <ttx> it was apparently not clear enough that "not following the release cycle and release completely independently" also meant "not being part of the common end-of-cycle release"
20:38:04 <ttx> So this adds a warning to the tag description to further clarify that
20:38:23 <flaper87> makes sense to me!
20:38:45 <ttx> Note, independently-released projects still get listed on the releases website
20:38:52 <ttx> just not under "mitaka"
20:39:07 <ttx> We seem to have enough votes in support
20:39:16 <ttx> so I'll approve this one now
20:39:33 <ttx> Thanks for him
20:39:46 <ttx> #topic Cross-project workshops at the Austin summit
20:39:50 <ttx> sdague: floor is yours
20:39:59 <sdague> we have 27 proposals here - https://etherpad.openstack.org/p/newton-cross-project-sessions
20:40:07 <sdague> about 1/2 the TC has weighed in
20:40:19 <sdague> we'll probably be targetting 21 slots
20:40:49 <sdague> and I'd like to do the sorting and slotting on Thursday
20:40:58 <ttx> (same as in Vancouver and Tokyo)
20:41:13 <sdague> so I'd ask that anyone on the TC that would like to voice opinions on the sessions please do so in the next 24 hours
20:41:32 <flaper87> ++
20:41:36 <ttx> hmm, no Vancouver only had 14
20:41:50 <anteaya> sdague: folks don't seem to feel that this is the right venue for my propsal (number 18) you can remove it
20:41:51 <ttx> so.. same as Tokyo.
20:42:14 <sdague> how does this time block on Thursday work for folks (in general)? as an adhoc time to do the scheduling
20:42:17 <sdague> anteaya: sure
20:42:20 <anteaya> thanks
20:42:30 <flaper87> sdague: should work for me
20:42:39 <ttx> sdague: should be ok once I'm done with releasing
20:42:52 <ttx> though I'm usually drunk then
20:43:04 <sdague> drunk works
20:43:11 <sdague> will make the schedule more fun
20:43:13 <jeblair> ttx: as long as there's a picture
20:43:19 <flaper87> ttx: don't drink alone, dude! Bring the beverage to the meeting
20:43:25 <ttx> jeblair: now it's all automated, no more paper
20:43:37 <ttx> I blame dhellmann
20:43:48 <jeblair> print out the git repo
20:44:06 <sdague> TC members welcome, though if you've expressed opinions on the etherpad, it should be mostly not required. We'll have whoever is here build some draft schedule, and get it out for friday for people to poke at conflicts
20:44:22 <ttx> sdague: ok so... TC review sessions today/tomorrow, then we gather somewhere to do scheduling fun
20:44:28 <ttx> on Thursday
20:44:29 <sdague> yep
20:44:41 <sdague> at this time block
20:44:57 <sdague> /done
20:44:58 <ttx> sounds good. I did not create placeholder sessions for the cross-project stuff on the summit schedule since I had no idea how many we'd run
20:45:03 <jeblair> sdague: just to be clear, the list of nicks for etherpad color -- that shuld be tc members only, right?
20:45:10 <sdague> jeblair: it should be
20:45:20 <jeblair> ok.  it may need some adjustment.
20:45:21 <sdague> we had a few interlopers, but that was mostly cleaned up
20:45:31 <anteaya> you still have sambetts|afk
20:45:46 <sdague> anteaya: I don't know if there are any votes recorded though, I'll look
20:45:51 <anteaya> k
20:45:56 <ttx> #topic Video design summit moderator advice
20:46:04 <anteaya> I talked to someone last night and they removed themselves and their votes
20:46:08 <ttx> We are organizing to record the video this week, should be ready sometimes next week
20:46:10 <jeblair> anteaya: thx
20:46:11 <sdague> anteaya: thanks
20:46:17 <anteaya> jeblair: sdague welcome
20:46:24 <ttx> I proposed we take the same people that suggested advice on the etherpad and volunteer them to record the video
20:46:41 <ttx> except dhellmann is away next week, and proposed to delegate his part to dims
20:47:05 <flaper87> sounds good to me
20:47:14 <flaper87> happy to help
20:47:17 <ttx> so this is the plan, it will probably look bad in the end but probably the best we can do in the remaining time
20:47:24 * jeblair thinks everyone should delegate their part to flaper87
20:47:35 <ttx> shooting from the beach
20:47:36 <flaper87> wait, what did just happen?
20:47:37 <shamail> I'll be glad to help with production or summary resulting from this video session
20:47:44 <flaper87> don't mess with my beach time
20:48:05 * dtroyer_zz has a beach nearby to shoot from if needed
20:48:06 * anteaya notes audio is way easier to edit and looks don't matter
20:48:12 <ttx> shamail: ideally we'd turn that into something more long-term and well-recorded at some point
20:48:35 <ttx> #topic Open discussion
20:48:41 <lifeless> sdague: fine for me
20:49:09 <lifeless> sdague: erm, actually, I may be on a call; will see
20:49:11 <ttx> Alright, so time to buy jaypipes, lifeless, jeblair and markmcclain some drinks
20:49:16 <lifeless> I will have commented either way
20:49:33 <ttx> sdague: if we don't need lifeless we could move the scheduling stuff earlier
20:49:39 <jeblair> cheers!  :)
20:49:53 <mordred> everyone needs lifeless
20:49:56 <sdague> ttx: sure, either way
20:49:57 * edleafe hands them all a virtual drink
20:50:00 <ttx> At 11pm I tend to be drunk /and/ grumpy
20:50:12 <sdague> ttx: feel free to counter propose an earlier time block
20:50:38 <ttx> sdague: an earlier time block would prevent lifeless from joining, so I'd like to be sure he can't participate anyway before suggesting an earlier time
20:50:38 <lifeless> sdague: this time slot is definitely free thursday
20:50:40 <sdague> I did this as default, because people are here. But it would let you be only medium drunk before participating if we move earlier
20:50:48 <lifeless> ttx: ^
20:50:56 <ttx> lifeless: ok, let's keep it
20:51:09 <flaper87> jaypipes, lifeless, jeblair, markmcclain u guys rock! Thanks for all the insights, work and lessons you've taught me so far :)
20:51:09 <ttx> and if I can't join you can probably figure it out
20:51:11 <sdague> lifeless: right, your friday
20:51:13 <edleafe> sdague: so thoughtful
20:51:47 <lifeless> sdague: yes
20:51:59 <sdague> ttx: yeh, it will be draft schedule, I'll circle with you later in doing any pushes to the site
20:52:01 <ttx> Anything else, anyone ?
20:52:07 <sdague> so we can do it without you.
20:52:16 <ttx> Release not looking too bad, except Keystone playing RC respin late fun
20:52:37 <sdague> if anyone has strong opinions about things looking like they might be near the cutline, please leave detailed notes to help with making those decisions
20:52:41 <ttx> and dhellmann being pretty good at placing vacation time :)
20:53:06 <ttx> good thing he mostly automated himself out of the release PTL job already
20:53:13 <dims> LOL
20:53:22 * flaper87 wants to automate himself
20:53:26 <sdake> i wish i could automate myself out of a job ;)
20:53:56 <ttx> Remember to vote for the TC election if you haven't already. Next week we'll gather the newly-elected members
20:54:32 <flaper87> ++
20:54:39 <ttx> (if we are still around)
20:54:54 <ttx> Any other discussion topic ?
20:55:01 <russellb> some group will gather, we assume
20:55:02 <annegentle> any need for a post prior to summit?
20:55:06 <annegentle> blog post
20:55:06 <ttx> Keystone RC calls, so I don't mind closing shop early
20:55:13 <annegentle> not at all :)
20:55:17 <flaper87> annegentle: don't think so, perhaps next week
20:55:22 <anteaya> ttx: thank you
20:55:30 <ttx> annegentle: we could talk about the mission statement change
20:55:31 <jeblair> finishing early is a good way to end the session :)
20:55:35 <flaper87> but I don't think we'll need one until after the summit
20:55:38 <ttx> but I think we covered it in a previous edition
20:55:47 * flaper87 stfu
20:56:04 <annegentle> flaper87: sounds good ttx prolly already covered well enough
20:56:11 <russellb> ttx: it's also not really substantial, not important to promote or anything
20:57:10 <ttx> russellb: it *is* important but I think a past article basically mentioned it as done
20:57:16 <russellb> ok.
20:57:25 <ttx> but then our friendly comms team can decide
20:57:30 * ttx checks
20:57:47 <flaper87> It was mentioned as done, AFAIR
20:57:53 <flaper87> I think we're ok, tbh
20:58:10 <ttx> hmmm
20:58:12 <flaper87> I don't mind doing a small blog post just for it but I think we're good.
20:58:20 <ttx> http://www.openstack.org/blog/2016/01/technical-committee-highlights-january-22-2016/
20:58:26 <ttx> it's a bit light, we don't even cite it
20:58:56 <flaper87> ok, I guess we can have a blog post mentioning this
20:58:57 <annegentle> heh
20:59:02 <ttx> so maybe cover that and farewell to our long-standing members / mention new elected members
20:59:04 <flaper87> I'll work on one and ask for reviews
20:59:13 <annegentle> I think it's nice to do a wrap up one yeah ttx
20:59:16 <russellb> ttx: +1
20:59:24 <ttx> http://www.openstack.org/blog/2016/03/technical-committee-highlights-march-21-2016/ mentions it too but light too
21:00:20 <ttx> Alright. Thanks everyone. This mitaka session went fast but it was not bad :)
21:00:30 <ttx> #endmeeting