16:02:40 #startmeeting incub_sync 16:02:41 Meeting started Thu Feb 26 16:02:40 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:45 The meeting name has been set to 'incub_sync' 16:02:46 #topic Barbican 16:03:08 #link https://launchpad.net/barbican/+milestone/kilo-3 16:03:17 gee, that's a lot of essentials :) 16:03:29 and feels a bit late overall :) 16:04:18 Yeah... the spec process took long for some of these 16:05:02 but a lot of folks committed to landing these by k-3 16:05:21 ok, we'll see 16:05:31 you might want to add assignees to the ones without 16:06:05 ttx yep, I'll get those assigned. 16:06:06 fwiw previously "integrated" projects are almost all running a FPF Thursday next week 16:06:15 FPF = all feature code must be up for review 16:06:20 leaving 2 weeks for final review 16:06:27 before feature freeze 16:06:49 but you can skip that if you don't expect to be overwhelmed by reviews 16:07:17 In other news, a bit of evolution on how I intend to run release tracking in Liberty: 16:07:25 https://wiki.openstack.org/wiki/Release_Cycle_Management/Liberty_Tracking 16:07:39 You can read when you have some time and let me know at another sync what you think of it 16:07:53 ok, I'll take a look at that for sure 16:07:59 This is also valid for bswartz Kiall and flaper87 ^ 16:08:07 yeah I saw it 16:08:09 alright.. questions ? 16:09:01 nope, no questions this week. 16:09:05 thanks ttx 16:09:23 bswartz: o/ 16:09:27 #topic Manila 16:09:27 hey 16:09:33 * flaper87 reads 16:09:36 damn, it's thrusday 16:09:41 #link https://launchpad.net/manila/+milestone/kilo-3 16:09:44 I started looking at out list of BPs in the last 10 minutes 16:09:44 again 16:09:53 It looks nice already 16:09:59 it's gotten longer since we last talked 16:10:02 A few undefined/unknowns to clean up 16:10:06 yeah 16:10:14 but otherwise nice progress 16:10:22 so I have one problems with BPs in LP 16:10:32 I like when things getmerged as yhou go, rather than pile up unreviewed until the end 16:10:35 they don't seem to change state automatically when code merges 16:10:43 bswartz: they don't 16:10:57 so I have to periodically go through and mark things implemented 16:11:07 there is no code for that because people rarely use the commit message codes appropriately 16:11:20 ok 16:11:28 well I need to do it again this afternoon 16:11:35 because this list is too long for my liking 16:11:42 i.e. people tend to use "Implements" in a commit message when the review actually doesn't close the blueprint 16:11:51 We could revisit that, I guess 16:11:53 we have a small core team 16:12:14 we need to simplify updating BP status if https://wiki.openstack.org/wiki/Release_Cycle_Management/Liberty_Tracking is the way forward 16:12:46 so manila is enforcing a FPF next week 16:12:50 I saw you talking about that 16:12:56 so setting some code like "Blueprint-compltion: 50%" that would translate itno whatever code in LP we'll use to match that 16:13:13 hmm 16:13:21 would that text go in the git commit? 16:13:37 that's one way to do it 16:13:55 because "implements" and "partial-implements" are not realiably used 16:14:01 does anything at all trigger in LP when a patch merges? 16:14:13 bswartz: currently nothing 16:14:25 I thought that bugs got closed or something 16:14:28 but we have the framework to make things happen (we close bugs for example) 16:14:36 oh, sorry 16:14:49 yes, on patch-merge we have the bug-update script run 16:14:57 on patch-propose, we update bugs and BPs 16:15:08 okay, so that script could be extended to do more, but it just does bugs today 16:15:12 'that's all jeepyb scripts from our infra 16:15:34 going through and updating BPs manually isn't that bad 16:15:39 right. That was the plan but cats would not use "Implements" safely and the update would be a bit unreliable 16:15:45 but it's one of those things that scale poorly as the team gets bigger 16:15:51 scales* 16:15:56 ideally it would be up to the assignee to keep that up to date, not you 16:16:16 Anyway, I'll let you continue to clean that one up 16:16:23 So you want to do FPF ? 16:16:27 yes 16:16:37 expect unhappy people on that day :) 16:16:39 in fact I've been telling people about it for 3 weeks in a row now so it's no surprise to anyone 16:16:54 good! 16:17:20 I expect some exceptions will be made, but I don't tell people that 16:17:24 That generally results in shorter RC1 (less release-critical bugs) and you can open Liberty earlier 16:17:34 so it's not necessarily blocking people for a longer time 16:17:34 yeah 16:17:47 hey I dropped in on the TC meeting this week 16:17:48 alright -- anything else ? 16:17:54 I saw the discussion about the release tag 16:18:09 hmm.. which one? 16:18:19 is the TC going to close on the definition of the release tag before going and defining others? 16:18:27 the discussion in the TC meeting 16:18:29 oh, the release tags. 16:18:44 no, we can add tags in parallel 16:18:56 from your blog post I sort of expected half a dozen or more tags 16:19:09 I hope to come back from the Ops Summit with plenty of tags 16:19:15 everyone is still wondering how tags are going to play out 16:19:24 one step at a time :) 16:19:36 when is this ops summit? 16:19:49 It's in 11 days in PHL 16:19:54 okay cool 16:20:03 that's it from me 16:20:26 col, have a nice week! 16:20:31 cool* 16:20:35 you too 16:20:37 flaper87: around? 16:21:50 ttx: yes 16:21:57 #topic Zaqar 16:22:04 #link https://launchpad.net/zaqar/+milestone/kilo-3 16:22:19 Looks like good progress to me 16:22:33 yeah, unfortunatelly we've been having "gate illness" 16:22:42 is it solved now ? 16:22:42 in the last week so, some progress was slowed down 16:22:46 almost 16:22:49 I'm debugging the last one 16:22:53 Planning to enforce FPF next week ? 16:23:00 or just review as-needed ? 16:23:25 just review as-needed 16:23:30 ok 16:23:35 we're not far from our goal so I'm happy 16:23:39 considering how many we are 16:23:49 That's all I had (with the wiki link above) 16:24:02 any question on your side ? 16:24:07 no, sir! 16:24:09 thank you! 16:24:14 alright! Have a great week 16:24:17 and travel 16:24:23 ttx: thanks :) 16:24:24 Kiall: you there , 16:24:25 ? 16:24:58 hey ttx 16:25:02 #topic Designate 16:25:10 #link https://launchpad.net/designate/+milestone/kilo-3 16:25:23 You seem a bit alone there 16:25:42 lol - there's one missing from the page ;) rest of the team is working on bugs and stability 16:25:46 Still feeling like you can deliver those ? 16:25:58 stability is good 16:26:25 Yep, we've been working through stability more than anything else after some of the bigger k1/k2 things have left us not so stable 16:26:27 (which is why I'd like to push less emphasis on velocity, as part of https://wiki.openstack.org/wiki/Release_Cycle_Management/Liberty_Tracking) 16:26:52 ok, nice 16:27:18 what else... I ssupect you won't self-enforce a FPF on yourself that would be silly 16:27:33 Lol, I might do ;) 16:28:38 alright -- questions on your side ? 16:29:01 Not today, though I probably will after reading that wiki page ;) 16:29:13 hehe yes 16:29:35 that will basically impact how many projects I feel comfortable "coordinating" releases for 16:29:51 Currently in fact I'm handling all of the incubated ones 16:30:02 so the release:cooridnated tag (if accpeted) would apply to you 16:30:24 (basically making you equivalent tagging-wise to the previously "integrated" projects 16:30:34 Okay, your thinking you continue to look after the incub projects then through L? 16:30:54 well, I plan to look after the release:coorinated projects, which is a set the team (me) defines 16:31:03 coordinated* 16:31:11 Sure, that makes sense.. 16:31:15 I still have to see how much I think I can chew 16:31:25 but simplifying tracking would help me take more 16:31:36 That would be if you want to, obviously 16:31:45 Looking at the wiki, weekly sync would be out, and as-neccessary syncs happen instead.. e.g. close to a release etc 16:31:48 I won't force anyone to be coordinated by me for sure 16:32:05 yeah, we basically wouldn't care so much tracking in-progress work 16:32:13 just tracking when to tag and what's in it 16:32:34 That makes more sense to me.. Most of the time, planning 6-8 months in advance just fails.. 16:32:35 trying to apply to features what we do for bugs (autocollecting all the complete ones and associate them to the milestone) 16:33:06 that still means you need to keep the state of blueprints current (at least so that we know when they are completed) 16:33:24 but no longer targeting them to a specific milestone, or needing to defer them once they miss 16:33:35 which is like 80% of out 1:1 16:33:47 anyone, I need to run. 16:33:54 "anyway", I mean 16:33:59 Sure - Cya :) Thanks! 16:33:59 have a great week! 16:34:02 you too 16:34:03 #endmeeting