20:01:37 #startmeeting tc 20:01:37 Meeting started Tue Nov 17 20:01:37 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:41 The meeting name has been set to 'tc' 20:01:41 o/ 20:01:46 Hi everyone! 20:01:52 hellooooo 20:01:55 Here is our agenda for today: 20:02:03 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:15 should have some time for open discussion at the end 20:02:20 #topic Update deprecation policy for changes not in coordinated releases 20:02:27 #link https://review.openstack.org/242117 20:02:35 Looks like this is pretty close now. 20:02:45 As I said before, it clarifies what the deprecation policy means for intermediary-released projects (before we add any) 20:02:53 The latest iteration has clearer wording 20:03:13 ttx: o/ 20:03:18 I think we can approve it now if people reapply their previous votes 20:03:21 thanks to everyone for working on improving the wording there 20:03:27 and to Jim for baring with us 20:03:32 :) 20:03:35 words are hard 20:03:38 no objections from me 20:03:40 jroll: no kidding 20:03:50 The landslide of +1s roll in! 20:03:52 that is much better, thanks 20:03:54 english is hard, let's write python 20:03:57 has 8 +1s now 20:04:04 Alright, we have a majority now. Will approve in 30 seconds unless someone screams 20:04:17 * flaper87 does the countdown in his head 20:04:20 dhellmann: man, I spent a whole day writing 4 lines of code yesterday. English so easy. 20:04:32 o/ 20:04:34 lifeless : heh 20:04:43 alright, it's in. Thx jroll for improving on the tag 20:04:52 woo, thanks y'all 20:04:52 #topic Add team:single-vendor tag 20:05:03 #link https://review.openstack.org/218725 20:05:23 We have 11 yes on this one, so I'll proceed to approve it unless someone screams 20:05:26 whole bunch of +1s 20:05:33 i think where this has landed is a nice compromise on concerns 20:05:34 nice work 20:05:38 Agreed 20:05:46 yeahn thx to jogo for driving most of it 20:05:53 approved 20:05:57 and again, baring with us 20:05:59 :D 20:06:11 #topic Add Fuel to OpenStack Projects 20:06:12 i +1d but also think it should be single-org -- the application of it to debian seems weird. 20:06:24 jeblair: ++ 20:06:32 jeblair: I had the same thought 20:06:32 agree 20:06:35 jeblair: you can propose the wording change now 20:06:45 I'm not totally convinced but could change my mind 20:06:50 #link https://review.openstack.org/199232 20:06:55 I'd like that wording change jeblair 20:06:59 So... I put this one back on the docket this week since we did not come to a final decision (approve or defer) last week due to lack of voters 20:07:09 We have one formal NO votes and two formal abstentions in the comments, that leaves 5 unclear positions 20:07:18 If we don't have enough YES to approve it, we'll defer it (which now means setting it to abandoned) 20:07:26 The group rejecting it should post on the review a list of requirements before they would change their vote 20:07:39 (if any) 20:07:48 jaypipes: jeblair: me too 20:07:51 jeblair: have you seen my update from just before the meeting started? 20:08:07 angdraug: just saw that 20:08:09 do we have people tat haven't expressed a position yet and would like to ? 20:08:12 more though, the Debian thing isn't 'Debian' working on it; its an openstack vendor 20:08:25 lifeless: right, my thoughts 20:08:37 but let's wait for the review :) 20:08:50 angdraug: link ? 20:08:59 comment on the review you've linked above 20:09:02 on the review ? Oh ok 20:09:04 reading 20:09:25 in short, we've covered all the remaining gaps that I've listed earlier 20:09:35 +1 20:09:59 worked really hard yesterday and today making all the gates work 20:10:01 i'm also happy to see the engagement from the fuel developers about further work. i think their getting involved is timely considering the changes we're making around zuul, nodepool, and our focus on multinode work 20:10:02 mordred: any position on Fuel ? 20:10:28 as a former cross-project PTL myself I appreciate cross-project work :) 20:10:40 yah - I'm excited about the stuff from bookwar 20:10:45 lifeless: same question 20:10:51 for the record, the thread from bookwar: 20:10:54 and I think that collaboration with the fuel team is potentially valuable as we look at multi-node testing 20:11:00 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079284.html 20:11:04 so i'm ready to switch to +1 20:11:21 jeblair: thanks! 20:11:25 ttx: I think we should, *but* jeblair's concerns are significant to me 20:11:46 the fuel team being honestly excited to work on the problems with us is the important bit - and it seems that they totally are 20:11:59 mordred: ++ 20:12:00 ttx: OTOH no project is perfect, its always an going effort to get better and more efficient and more coverage etc 20:12:01 (+1 from me) 20:12:01 jeblair's and infra's concerns in general were the reason for my abstaining, if Jim is ok with this, I'm ok with it. 20:12:33 lifeless: ++ 20:12:33 yeah, I thought Jim's concerns were valid, I was just fine with giving the Fuel team the benefit of doubt 20:12:43 +1 party starting 20:12:44 same, as i said on the review, i think it seems wrong to +1 this with an important cross project -1 on it 20:12:47 ttx: me too, well stated 20:12:49 since all decisions can be changed 20:13:12 +1 now 20:13:16 ttx: you're so much nicer than i am :) 20:13:30 You do bad cop 20:13:43 I di good cop 20:13:45 do* 20:13:51 #link https://wiki.openstack.org/wiki/Fuel#People 20:13:54 anyway, looks like we have more than enough to approve now 20:13:54 but yeah, mordred succinctly expressed my feeling 20:14:06 I've appointed bookwar and igorbelikov as liaisons to Infra team 20:14:13 obviously the effort that was statred must continue 20:14:22 I must know bookwar because that's the best IRC nick ever 20:14:25 please feel free to reach out to them on any fuel/infra cross-project issues 20:14:41 but I really think the Fuel team is now working hand in hand with all the other teams 20:14:57 annegentle: we actually talked in vancouver i think.. :) 20:15:09 so the process was painful but I think it was positive for everyone 20:15:17 alrightn approving now 20:15:37 that n key is too close to the , key 20:15:52 angdraug: all set! 20:16:01 thanks a lot everyone! 20:16:09 angdraug: thank you 20:16:10 angdraug: congrats! 20:16:17 thank you for trust guys. we are happy to work within larger community 20:16:29 woot! 20:16:32 bookwar: ++! :) 20:16:37 thank you! 20:16:37 we really are excited to work with all of you ) 20:16:43 #topic Comms workgroup report 20:16:46 angdraug: congrats! 20:16:47 * mordred hands the fuel team a box of cookies with half a cookie in it, apologizes for having gotten hungry 20:16:48 welcome angdraug and all! 20:16:51 annegentle, flaper87: where are we standing on the communications front ? 20:16:56 looks like some blogpost is in order 20:17:04 ttx: yup, it's 20:17:07 with what we approved last week and this week, lots of material 20:17:14 ttx: we both unabashedly admit doing nothing in the last 2 weeks :) 20:17:16 we just synced yday (o was that the day before?) 20:17:22 yeah definitely time for a post 20:17:43 do we have any improvement ideas from last six month's of the plan? 20:18:00 annegentle: I think that worked reasonably well 20:18:04 We should send a request for feedback 20:18:24 I'm curious to know, after 6 months, whether ppl still read these communications 20:18:29 ttx: I think so, need more twitter power possibly, but other wise it's ok 20:18:29 you can include it in the post 20:18:39 flaper87: yeah request for feedback in the post works 20:18:42 ttx: ha, in small letters ? 20:18:47 "if you read this, please send $1 to flaper87" 20:18:48 :P 20:18:52 hee 20:19:11 "flaper87 will blog for food" 20:19:25 OK, so post should have newest additions to governance, anything else we want to discuss/get input on? 20:19:27 w000h00000 20:19:30 lol 20:19:37 anything from summit, joint tc/board meeting? 20:19:37 okonomiyaki! 20:19:54 Themes ? 20:20:06 We might want to mention something about the Mitaka themes 20:20:13 flaper87: difficult to mention since we didn't make any real change yet 20:20:38 cross-project comms? 20:20:49 annegentle: same, we haven't reached a conclusion there 20:20:51 themes would be good 20:20:54 sure, but we did come up with sort of a list. Or at least mention there's that effort going on 20:21:00 I don't think we have to make the change to talk about it 20:21:02 transparency! 20:21:04 annegentle: with you and Mike always being in some tropical island 20:21:11 lifeless: yup, that's were I was coming from 20:21:34 ttx: wishful thinking, I just wrangle kids 20:21:55 flaper87: lifeless: yeah I agree, mention early/often 20:22:05 alright... so let's say you post some draft and we'll add to it ? 20:22:11 sounds good 20:22:20 any other comms problems to tackle? 20:22:26 this release? 20:22:39 no I think we are good 20:22:45 as far as TC comms go 20:23:13 ok, next topic ? 20:23:37 #topic Project Team Guide workgroup report 20:23:44 #link https://etherpad.openstack.org/p/mitaka-crossproject-doc-the-way 20:23:50 We discussed next steps for the project team guide at the Design Summit 20:23:58 There are a number of topics we want to cover this cycle 20:24:06 like better explain the benefits/tradeoffs for the various release models 20:24:23 or common principles like API deprecation rules or the fact that you can expect a DB and a oslo.messaging queue to be around 20:24:33 (and soon a DLM!) 20:24:39 We want to explain tags and point to projects.yaml as well 20:24:47 And finally document community best practices like IRC bouncers or gertty 20:24:55 And then explore the wiki for other things that should be moved to the guide 20:25:13 I'll drive most of this but would not mind help :) 20:25:20 More recently a new question was raised in several reviews 20:25:30 Those are adding step-by-step instructions to setup new project git repositories, or moving them from the Infra guide "project creator guide" to the Project Team Guide 20:25:40 Personally I would prefer if the project team guide focused on its original objective, which is to document the culture 20:25:47 and did not turn into an instruction manual 20:25:53 +1 20:25:58 But that may mean we are missing a true "project setup guide" since this apparently doesn't belong on the Infra guide either 20:26:11 Suggestions on that ? Should we just create a new guide for that ? 20:26:16 i thought we talked about that in the session too and the reception for moving it to the ptg was favorable... 20:26:20 I wasn't able to attend the summit session but, just like in our previous project team guide sprints, I'm happy to help with this one. 20:26:28 hrm 20:26:43 ttx: and i don't think the suggestion is to move git repo setup there... 20:26:47 having a proliferation of guides seems like it's going to make it harder to figure out where to put things, rather than easier 20:27:04 ttx: the parts we're talking about moving there are things like "how do openstack projects use unit tests" 20:27:11 dhellmann: it's about the reviewers, not necessarily the publishing 20:27:14 which seems like a good fid to the ptg for me 20:27:19 good git 20:27:20 jeblair: there are test setup instructions proposed around release notes that really sound like a chapter of the infra guide 20:27:20 grr 20:27:22 dhellmann: The converse issue is that if the PTG gets too long and too detailed, many people won't want to read or watch changes. 20:27:22 fit 20:27:32 new swear phrase: "good git!" 20:27:33 annegentle : then let's get more reviewers? because it's also confusing for folks to find this information 20:27:51 yeh, and you don't get more reviewers by splintering projects 20:27:52 it would be useful to have one manual telling us how to do our work, even if it covers both theory and practice 20:27:58 jeblair: what's being proposed right now is a lot of code snippets and commands 20:28:08 it can be a dedicated chapter 20:28:12 we could, you know, exhibit the trust we keep suggesting other projects show by letting more folks have +2 on the team guide 20:28:18 ttx: that seems like a new thing we didn't talk about then. 20:28:19 I'm more for having it all in the same project/repo 20:28:25 dhellmann: ++ 20:28:31 dhellmann: wouldn't hurt since I seem to be the only one reviewing those days 20:28:39 dhellmann: I think people want to publish this info, but in one case where a bunch of bug triaging info was added to the infra manual, that team didn't want to be responsible for reviewing it... I might be mixing guides here but I think it's an overall pattern. Small review teams, and small repos are fine, but publish to the same place 20:28:46 jeblair: it is, which is why I'm asking 20:29:02 annegentle : right, I'm suggesting that more of that should go into the project team guide 20:29:09 jeblair: please review what's being proposed, I think it clearly crosses the line from policy and principles to howto 20:29:21 dhellmann: ok yeah, and I think there's need for howto 20:29:37 ttx: really I think there could be a howto chapter 20:29:39 that's another repo 20:29:41 #link https://review.openstack.org/#/q/project:openstack%2Fproject-team-guide+is:open,n,z 20:29:43 then we publish to one place 20:29:49 ttx: can do 20:29:57 annegentle: but then project setup instructions are split between infra guide and project team guide 20:30:05 annegentle : splitting the repos makes it confusing for contributors. Let's just give the right folks +2 on this repo. 20:30:27 yeh, and it is git, we can always revert changes that might be bad 20:30:30 when I talk about a third repo, it's so that the project setup howto is in a unique location 20:30:43 ttx: I'm OK with moving the release notes setup instructions to the infra manual, if that's where we're going to put *all* such instructions 20:31:01 dhellmann: ideally we'd put all such instructions in one repo, sure. 20:31:08 ttx: who would be the reviewers for that new repo? 20:31:09 dhellmann: and that is the issue. Only half the instructions live there right now 20:31:11 dhellmann: I was just mentioning that there was a bit of a problem with that 20:31:20 dhellmann: Anyone who cares 20:32:12 Currently, a project team wanting to set up a new project repository has to read the infra guide. And we are adding material to the PTG about setting up new repositories as well 20:32:15 I think that's confusing 20:32:20 ttx: ok, maybe we should talk to fungi and the infra cores about (a) adding these directions to the infra manual and (b) giving +2 to more folks on that repo 20:32:21 I want everything in one place 20:32:27 Selecting reviewers is easy: start with this team, and watch who else reviews, etc., with regular additions, removals, etc. 20:32:41 If that's not in the Infra guide nor the PTG, then I'm fine with a third repo called project setup howoto 20:32:50 how about it goes in the reno repo? 20:32:55 I just want everything in the same place 20:32:58 jeblair : reno is not openstack-specific 20:33:18 hm. jeblair is onto something though, about putting docs nearest to code 20:33:20 hm 20:33:20 jeblair : also, you would have to know to look at the reno guide to manage release notes before you know what reno is 20:33:38 I thnk that's one of the tricky bits 20:33:43 annegentle: we could put it in cookiecutter 20:33:45 it's "what are the things I should look at" 20:33:50 ttx: same problem 20:33:54 right, we need one starting point 20:33:55 ttx: you have to know about cookiecutter 20:34:03 it sounds like that is PTG 20:34:23 some info is in the infra guide and will stay there 20:34:24 being a starting point you need to either contain the info, or links to the info for everything else 20:34:47 sdague: we can always point to another guide from the PTG (or from the infra guide) 20:34:57 yah. I think release notes guide being in reno is fine (for instance) if the main guide says "we use reno for release notes" 20:34:58 sure, but you need to tell people why they are going theere 20:35:11 * annegentle doesn't know cookiecutter 20:35:16 mordred : we don't put the instructions for setting up CI in the zuul documentation. How is this different? 20:35:16 similar to "we use tox for driving virtualenv unit tests" and "we use testr as a test runner" 20:35:29 and I'm fine with principles and policy to be in the PTG. I just don't want to turn something that is a policy guide into somethign only devs will read 20:35:42 the reno guide has generic instructions, but we do have openstack-specific standards we need projects to follow for their jobs to work 20:35:50 dhellmann: I think there needs to be a top-leve thing which tells people what general concepts they need to know 20:35:52 and yea 20:35:58 ttx: who do you expect the audience to be? 20:35:58 openstack specific instructions on how to use the thing 20:35:59 dhellmann: ah ok 20:36:09 sdague: any project team 20:36:20 sdague: it's about redirecting questions to a page, providing wider support nets than 1:1 Q:A 20:36:20 like "for tox, please use skipsdist and use_develop and do not set system-packages to true" 20:36:23 I'd like the audience to also include any org that is becoming involved in openstack 20:36:28 those are openstack specific things about a thing which has its own manual 20:36:40 if you just pointed to the tox manual, it would not help someone get started in the right way 20:36:45 mordred : right, and in this case it's specific names of directories and tox environments 20:36:48 mordred: right 20:36:48 yup 20:37:34 these are starting to seem like project team guide things to me. 20:37:39 sdague: at the very minimum we should make sure it's all in a specific chapter, if it stays in the PTG 20:38:05 I'm OK with that. I added these things to release team page because they seemed release related, but we could make a new chapter for them. 20:38:31 We could all put them in the "project setup guide" chapter that krotscheck has been pushing 20:38:39 yeah, I'd make a new chapter for them 20:38:41 there's also the organizational question of: do we have 5 sections that each say "add this job to zuul" or one section that says "add these 5 jobs to zuul"? 20:38:41 sure, that makes sense 20:38:57 jeblair : one page, several sections, because not all of this applies to every project 20:39:05 ideally these are all "articles" in a guide that everyone can publish to... it's just that the overall TOC isn't really solved, yet. 20:39:19 Since you all seem to have an opinion on what belongs to he PTg and what does not, it would be awesome if you could actually review the changes there. 20:39:30 jeblair : does the project creator's guide move from the infra manual to PTG? 20:39:34 ttx: +1000 20:39:45 because otherwise I'm inclined to ignore you 20:40:01 ttx: ++ 20:40:02 ttx: for example we started a docs contributor's guide, but had many debates about whether it belonged in the infra manual 20:40:17 o/ 20:40:22 and go with my own definition rather than try to guess yours and apply it 20:40:24 ttx: and I agree on the "please review" call but honestly we have to focus efforts -- and publish as easily as possible 20:40:53 my view is, publish as much as you want to review 20:41:03 ttx: i'm #4 in reviews, does that count? 20:41:17 annegentle: I tend to agree that published somewhere is better than not publish at all 20:41:36 jeblair: it counts! I just felt very lonely lately 20:42:18 * flaper87 hugs ttx 20:42:19 dhellmann: that's a really good question, and i don't have an immediate answer. 20:42:31 anyway, I think we have a way forward. Collect opinions on reviews, then worst case scenario include it in the pTG for the time being 20:42:33 * flaper87 is guilty for not doing much reviews in PTG 20:42:36 jeblair : food for thought. I get that keeping it in the infra manual makes it easier to keep it up to date. 20:42:42 flaper87: you're #3. 20:42:48 go flaper87 go :) 20:42:54 http://stackalytics.openstack.org/?project_type=all&module=project-team-guide&release=all 20:42:58 I brag but I'm not even sure I'm #1 20:42:59 jeblair: holy crap... you suck at reviewing PGT 20:43:02 * flaper87 ducks 20:43:02 * dhellmann hands ttx an eclair 20:43:06 PTG* 20:43:38 ok, next topic ? 20:43:55 ++ 20:43:55 #topic Next Tags workgroup report 20:44:00 #link https://etherpad.openstack.org/p/mitaka-crossproject-next-tags 20:44:05 This was mostly a feedback session where we brainstormed potentially useful tags 20:44:11 The first set are the wrongly-named integration tags 20:44:17 i.e. tags to describe that a project for example has a horizon panel, a devstack plugin or heat resources 20:44:25 We had one proposed by sdague for devstack last cycle but it got stuck on the question of whether to distinguish between mainline and plugin or not 20:44:37 Second set are the team tags, we might still want a "large-team" tag at some point 20:44:46 Then we have contract/assert tags, which got a boost with the upgrade tags from Dan 20:44:53 Someone suggested a API versioning assert tag 20:45:03 probably to back up mordred's "no more deprecation" call 20:45:15 Next we had QA tags, to describe the extent of testing done in each project 20:45:26 And finally horizontal team support tags (we might want a new one for stable branch team, and potentially others) 20:45:39 I don't think we formally need a workgroup to drive that anymore, since that wasn't very successful in Liberty... Feels like waiting until someone cares enough to propose one is good enough 20:45:53 I like waiting until people care 20:45:59 so I propose to disband the band of brothers 20:46:05 ++ 20:46:07 we even get tags from people who have quit openstack that way 20:46:10 (and sisters) 20:46:15 I felt that was pretty much the way it was working 20:46:16 ttx: :) 20:46:28 heh 20:46:37 we did one meetig and got one tag proposed. We got more just by nudging Dan Smith 20:46:55 there's a workflow 20:47:01 so I won't bore you to death with next-tags WG progress repotrs anymore 20:47:04 progress! 20:47:05 I do like that we saw tags proposed 20:47:11 ttx: ++ disband :) 20:47:18 yes we create committees, but we also KILL THEM 20:47:47 nice 20:47:53 that said, if anyone is super-interested by one of the themes I just mentioned, feel free to dive in! 20:48:02 #topic Open discussion 20:48:37 Anything else ? Any outcome from the Design Summit that we need to work on to make happen ? 20:48:57 I feel like the DLM stuff is making slow and steady progress 20:49:16 Cross-project comms overhaul is also on a track 20:49:41 mordred: what's the next step on the suggestion to never ever ever again deprecate an API ? 20:50:06 I thought lifeless was going to write up something 20:50:29 mordred, annegentle: we also signed up at the TC/BoD meeting to propose a slightly-modified mission statement 20:50:29 so, along those lines - https://review.openstack.org/#/c/245745/ - holding meetings in #openstack-dev or not for cross project things 20:50:35 lifeless: right? or have I been drinking too much hibiki 21 again 20:50:38 mordred: ttx: yep we sure did 20:50:41 sdague: good one 20:50:53 annegentle: I need to sync back up with you on that don't I? 20:50:55 lifeless: are you? 20:50:55 sdague: I'm -1 on it after thinking on it 20:50:57 hmmm... hibiki 21 20:51:05 mordred: there's an email... it has words in it... 20:51:21 annegentle: I like words 20:51:30 annegentle: ok 20:51:36 annegentle: and your alternative is? 20:51:44 sdague: it being #openstack-dev channel for cross project meetings. Probably fine for service-catalog though. 20:51:53 * annegentle clicked the link 20:52:35 annegentle: oh, right this was me trying to put our weekly checkpoint into irc 20:52:36 sdague: I think meeting channels for meetings is better generally than picking a "room" channel 20:52:47 annegentle : ++ 20:52:48 annegentle: sure, and they are all full 20:53:03 sdague: maybe it's time for #openstack-meeting5 20:53:06 i would prefer to keep discussion channels open for discussion and have meeting channels; i'm fine making more meeting channels, including a dedicated 'cross-project-meeting' channel (even if it's usually unscheduled) 20:53:07 sdague: yeah let's stick with meeting channels, add more if needed. I think in the session we talked about #cross-project-meeting ? 20:53:07 maybe 20:53:26 we hit a similar issue trying to move the release team meeting 20:53:28 having a dedicated cross project meeting room seems good 20:53:30 new channels are pretty low-cost 20:53:35 jeblair: ok, good 20:53:35 mordred: I am writing something 20:53:43 mordred: on the DLM side, its not on my todo to write 20:53:44 lifeless: ++ 20:53:45 sdague: I want to go on a clean-up rampage first 20:53:47 mordred: I am writing other things ;) 20:53:51 especially as the overall time contention would be less 20:54:02 because it won't be Nth subteam of new project 20:54:04 ttx: do we have meetings on the schedule that aren't happening? 20:54:05 lifeless: oh. piddle then 20:54:10 lifeless: mordred so, no one is working on the "never ever ever deprecate APIs thing" ? 20:54:13 dhellmann: of course 20:54:14 ttx: I guess I need to write a thing on the API topic 20:54:25 ttx: I'll put that on my list 20:54:27 flaper87: I'm working on a deprecation thing for libraries 20:54:35 it would probably be good to have audit of existing meetings to parse the logs and figure out if they are happening 20:54:35 lifeless: roger 20:54:37 ttx: then yeah, we should clean that up and see if we still need another new channel 20:54:39 mordred: "Never, ever, ever, ever deprecate an API." hth 20:54:49 lifeless: yah - I totally thought you were going to write a thing on api deprecation because you were already writing the one for libraries 20:54:49 and if they are happening if they are all really > 30 minutes 20:54:58 because I expect there is a lot of over allocated time 20:54:59 rigt. I might take that action 20:55:08 lifeless: but I'm more than happy to write it 20:55:14 wait - I thought it was deprecate, but never remove? 20:55:15 lifeless: just wanted to make sure I wasn't stealing your fun 20:55:18 edleafe: yes 20:55:22 edleafe: that's what it actually is 20:55:33 mordred: ah, just checking 20:55:35 mordred: right, so I think in libraries we can remove, but it needs to be a long period 20:55:36 good thing i'm not writing it 20:55:46 ok, so is there an #agreed that we'll build an openstack-meeting-cp ? 20:55:47 mordred: I'm happy to help you but not sure I can take lead on that 20:55:48 jeblair: we need some way to check that a meeting has been happening often enough to justify blocking the slot 20:55:52 mordred: lets compare notes and so on, bu t yes, differen tthings 20:55:57