21:02:00 #startmeeting nova 21:02:01 Meeting started Thu Oct 17 21:02:00 2013 UTC and is due to finish in 60 minutes. The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:05 The meeting name has been set to 'nova' 21:02:09 hello, everyone! 21:02:13 hi 21:02:15 hi! 21:02:17 hi. 21:02:20 hi 21:02:22 hi 21:02:29 congratulations on the havana release! \o/ 21:02:35 woo 21:02:42 yay 21:02:42 !! 21:02:43 jog0: Error: "!" is not a valid command. 21:02:49 i considered canceling today ... as dansmith put it, "today should be a day where the class watches a movie while the teacher sleeps off her hangover" 21:03:01 heh 21:03:05 i was amused 21:03:09 lol 21:03:12 but we can catch up quickly :) 21:03:24 so things going on ... design summit! 21:03:29 session proposal deadline is today 21:03:38 and starting tomorrow we will be deciding on the session list and making a schedule 21:03:47 hopefully will have the draft schedule completed by the end of next week 21:04:25 Icehouse blueprints - please file them :-) 21:04:38 to get them reviewed, the trigger is to target them to a release milestone (icehouse-1/2/3) 21:05:01 at some point (probably next month) we're going to go through and close most things untargeted as effectively abandoned 21:05:04 to clean up the list a bit 21:05:23 i'll post to the ML about that, as well 21:05:30 russellb: other that adding the proposal - here http://summit.openstack.org/cfp/details/246 - is there anything else i need to do to to bring it to your attention for review tomorrow? 21:05:38 * russellb looks 21:05:50 oops - wait 21:06:05 link isn't working 21:06:16 yeah - just a sec *blush* 21:06:33 http://summit.openstack.org/cfp/details/247 ? 21:06:53 yes 21:07:01 looks good 21:07:04 thanks 21:07:08 np 21:07:15 any other blueprint questions? 21:07:25 err i meant summit 21:07:28 but summit or blueprint i guess 21:07:46 next thing ... we've been talking a lot about CI for each compute driver 21:07:54 congrats to the VMWare team for getting theirs up and running! 21:08:06 yeah! 21:08:11 you will now start seeing "VMWare Mine Sweeper" vote on reviews 21:08:20 very exciting 21:08:40 tjones: really, totally thrilled to see the progress, setting a good example for others 21:08:41 adding +1 on success, nothing on failure while we triage. −1 once we are confident 21:08:46 even beyond just nova 21:09:21 so let us know how things continue to progress 21:09:27 will do 21:09:45 and I think that's all the project status stuff I really had for this week 21:09:54 anyone have any topics for today? 21:10:25 russellb: yeah 21:10:41 russellb: yeah, but jog0 go first 21:10:45 we should make it clear what is required from a BP detail wise 21:11:08 * mrodden1 lurks 21:11:14 yeah, i'm not sure we have any documented guidelines for that ... 21:11:21 yet 21:11:24 :) 21:11:47 one thing is I think we should have the docImpact details in the blueprint 21:11:59 https://wiki.openstack.org/wiki/Blueprints 21:12:09 that's the page we should use 21:12:18 unless we want to start Nova/Blueprints for some nova specific guidelines 21:12:23 and then link over to this one for some general info 21:12:45 but I do like the docimpact info on there 21:12:57 either on the blueprint itself, or the linked design wiki page 21:12:58 +1 21:13:07 http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/ 21:13:12 is what annegentle wants 21:13:19 ok great 21:13:29 i think the other thing we need to do is encourage more design info and review up front 21:13:34 ++ 21:13:44 and with some additional people helping review blueprints, it should be more practical to do that 21:14:18 ++, thats all for me thanks 21:14:21 cool 21:14:26 some other things to think about ... prioritization 21:14:33 we need to be careful how much we approve at given priorities 21:14:40 because we only have so much review bandwidth 21:14:49 +1 at least set expectations more clearly I guess? 21:15:03 yeah, not sure how to best handle it yet 21:15:24 I liked the medium we track it and talk to people 21:15:32 low, best of luck if we have time? 21:15:51 another problematic case is when people sign up to deliver in icehouse-1, but deliver in icehouse-3 21:15:51 and we end up with 80 blueprints in icehouse-3 21:15:51 that basically happened in havana 21:15:51 and we're *still* catching flak for not merging everything in h3 21:16:09 yes, that's the project-wide proposal for how to apply low vs higher now 21:16:14 yeah, good point 21:16:15 but probably need to communicate that well 21:16:29 I guess we should reject more features down to low, if they slip? 21:16:34 +1 21:16:40 +1 21:16:44 i like that a lot actually 21:16:56 you broke the social contract, so it's back to best effort if we can :) 21:16:57 yeah, agree at the beginning all the medium and above 21:17:12 then low for everything else from that point, if at all 21:17:18 How does a group determine which window to put it in? 21:17:30 leif: whichever one you think you can have it completed and reviewed for 21:17:30 when they thing they will get it done? 21:17:34 think^ 21:17:34 it's on the developer(s) 21:17:36 everything at medium to start? 21:17:38 is there any way to show how complex a BP is likely to be to implement ? If so, you can push for those to make i-1, i-2 or be dropped? 21:17:56 tjones: we can guess :) ... and hopefully the dev proposing it has an idea 21:18:05 tjones: hopefully the BP description will say that 21:18:14 So rules motivate getting a late slot. 21:18:24 ok - they should be in the BP desc. I didn't see a way to explicitly say 21:18:33 there's also a downside to getting a late slot 21:18:40 much less likely to accept complex/invasive things later 21:18:54 and you're also at much higher risk at competing with a higher review load on the backend 21:19:17 so it's really in everyone's best interest to deliver as early as is practical 21:19:25 okay. 21:19:28 tjones: there is no specific spot for it, but the BP should cover that level of detail (how it will be implmented risk etc) 21:19:30 so, wait, I got distracted for a sec.. 21:19:37 * russellb waits 21:19:45 is the proposal that everything starts at medium and can slip to low if need be? 21:19:58 I thought johnthetubaguy said that, but I definitely don't think that's workable 21:20:00 i don't agree everything gets medium automatically 21:20:03 okay 21:20:04 I think everything we bother to track is medium 21:20:11 right, okay 21:20:15 yeah, but still, a lot will be Low 21:20:16 or higher 21:20:20 gotcha 21:20:26 yeah, things are low by default I think 21:20:30 lots of stuff is "nice to have" but we'd be OK if it didn't make it 21:20:32 I would word that differently 21:20:34 ok 21:20:50 not "everything we track is medium or above" because... we're tracking all that stuff in the tracker, even low stuff, 21:21:04 but rather "everything we expect to be mandatory reviews" or something like that 21:21:35 I guess its important stuff, that got a slot first, that we thing we will have time to review 21:21:36 I mean, we don't have to quibble over words, I was just worried something different was being proposes 21:21:37 so ... if it's mandatory reviews ... should we have core reviewers sign up on a blueprint before bumping it above low? 21:21:38 er, proposed 21:21:45 should we confirm that we have people willing to "sponsor" it? 21:21:58 hmm, that would help with the blueprint review, I quite like that 21:22:13 russellb: maybe, that's kinda scary given how many mediums there were 21:22:19 but I can see that for high ones for sure 21:22:20 yes, it might mean we have more low 21:22:26 but maybe that's a better reflection of reality 21:22:29 vs me just making stuff up 21:22:30 +1 21:22:32 * mrodden assigns all mediums to dansmith by default. 21:22:33 sure, if that's going to make more things low, 21:22:36 then I'm down with that :) 21:22:37 +1 21:22:50 yeah, more low things sets the expectation better I think 21:22:59 * dansmith -2's all mrodden's patches 21:23:02 and is a way to control how much we actually think we can review 21:23:07 that already happens 21:23:18 and *may* even help encourage some companies to put more devs on general work :) 21:23:21 I think this is an excellent thing to shoot for, 21:23:25 if they have core folks, they can sign up on reviews, etc 21:23:34 I like the idea of having cores assigned to BPs but I think more important is a review of the BP itself 21:23:48 but lets make sure we have a back way out if we start actually reviewing blueprints and decide that it's not going to work to try to put someone's name on everything :) 21:24:21 heh, fair enough 21:24:22 so maybe two cores for a medium and four for a high? 21:24:27 a nice goal perhaps ... 21:24:38 four huh? 21:24:38 ideally, if core's had an incentive to sponsor a BP they would probably have more incentive to review the changes associated 21:24:39 bold 21:24:39 I think a better BP review (make sure the propsal is good and the design is sound etc) will get us further 21:24:44 for less effort 21:25:12 well, has to pass review by cores to get a priority? 21:25:22 russellb: four to spread out the liability of one person being jammed up and blocking obligatory review of the blueprint because they're half the folks committed 21:25:42 could even be 1 for medium, 2 for high, and 3 for essential ... it'd be better than now 21:25:42 but i guess 1 doesn't necessarily guarantee it gets the review time 21:25:56 dansmith: lets try doing this for I-1 for high or above only and see how it goes 21:25:59 I like having more than one on all of them, to review the review, etc 21:26:14 johnthetubaguy: exactly 21:26:15 jog0: heck, might as well try for the mediums too 21:26:16 before we commut fully 21:26:27 russellb: sure 21:26:36 concerned about bandwidth and flexibility 21:26:40 jog0: well, I think we might as well commit to the whole thing for mediums and above for I1 and just not promise to keep it up until we decide we like it 21:26:41 i like that, put this out as an experimental process if icehouse-1 and see how it goes 21:26:49 yeah 21:26:53 +1 21:27:08 awesome! i like this. 21:27:17 works for me. we should have a BP review party at the summit 21:27:19 I like this right now 21:27:22 * dansmith pulls a comstud 21:27:26 lol 21:27:28 dansmith: but you reserve the right to hate it tomorrow? 21:27:33 of course 21:27:35 * russellb nods 21:27:38 subject to change without warning 21:27:39 * johnthetubaguy giggles 21:27:42 where we divvy up the BPs 21:28:00 jog0: that sounds good and will encourage people to get BPs in before the summit 21:28:17 cyeoh: yeah :( 21:28:21 I don't think we can have them all filed by summit, many will be created during it 21:28:22 skip the drinking and have a nice geek blueprint review party? :-) 21:28:46 many will be created during, and a *bunch*, maybe most, the week after as a result of dicussions and decisions 21:28:49 we could start with what we have 21:28:53 we could 21:29:02 or just go to the parties 21:29:09 i'm usually pretty fried at night, doubt it's that practical 21:29:17 i may be hiding in a room to be alone for a few minutes 21:29:35 speaking of summit and hanging out ... we should really all try to spend some time hanging out at the summit 21:29:37 team building! 21:29:51 I would vote for doing something in this meeting the following week? deice what you fancy 21:30:17 johnthetubaguy1: yeah, that's fine, but we can dabble a bit in the meantime 21:30:22 +1 21:30:28 there's not many proposed yet 21:31:06 ok, so, lots of improvements for issues we've had wrapped up in this discussion, really great stuff 21:31:07 thanks guys 21:31:27 mriedem: you had a topic? 21:31:39 russellb: just a call for a core review on a patch, 21:31:46 russellb: https://review.openstack.org/#/c/46718/ 21:31:55 that was falling to the bottom of the review pile i think in one of the stats pages 21:31:59 cyeoh looked at it last night 21:32:15 the author has been kind of asking intermittently but his timezone doesn't help much (china) 21:32:15 yeah, pretty old it seems 21:32:26 i told him i'd ask here 21:32:29 mriedem: tell him to move 21:32:31 nice of you :) 21:32:57 anyway, that's it fro mme 21:33:04 and i got mock working! woohoo 21:33:08 heh 21:33:14 you can all enjoy reviewing that soon 21:33:32 do you have a sponsor for that patch? :-p 21:33:39 my mock one? 21:33:48 just a joke and reference to the last discussion 21:33:59 oh, missed most of it getting these damn tests to run 21:34:02 which was actually only in reference to blueprints, not individual patches 21:34:05 yeah 21:34:12 any other topics today? 21:34:13 all i heard was it's ok to dump blueprints in I3 21:34:17 :) 21:34:19 LOL 21:34:25 did we chat about summit sessions already? 21:34:29 mriedem: and assign then to dansmith 21:34:49 heh 21:34:51 johnthetubaguy: not in much detail, just mentioning that today was the deadline 21:34:59 johnthetubaguy: did you get my message about meeting tomorrow to start the review? 21:35:15 russellb: cool, ah, not yet, been out this evening 21:35:40 just checked and we have **19** more proposals than time slots (31) 21:35:46 johnthetubaguy: hm, was a couple days ago 21:35:46 johnthetubaguy: will msg 21:36:40 johnthetubaguy: any you want to discuss now? 21:38:47 any other topics from anyone? 21:39:27 was there any more news on the midyear meetup? 21:39:33 oh, good question 21:39:35 ... no 21:39:41 and that's my fault, basically 21:39:58 dang right it is 21:40:13 that's something I can commit to 21:40:13 we're having a post linux.conf.au (Jan) meetup for those who will be around 21:40:21 the statement, not the meeting 21:40:23 cyeoh: nice 21:40:51 comstud: i can also commit to talking bad about at summit while you're not there to defend yourself 21:41:05 :) 21:41:18 i'm sure you wouldn't be the first 21:42:48 mrodden: so, i need to follow up on that, will work on it 21:42:54 thanks for coming everyone! 21:42:58 russellb: k thanks 21:43:32 #endmeeting