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