Meetings/Horizon/Feb17log


 * 12:02:43  looks right to me
 * 12:02:51 Hmm.
 * 12:03:11 Doesn't seem to like me trying to start the meeting.
 * 12:03:20  "Once the #startmeeting command has been issued, the bot should start the meeting. If the bot doesn't respond to this command, ask for assistance in #openstack-infra. "
 * 12:03:23  that's from the wiki!
 * 12:03:27  seems relevant
 * 12:03:38 freenode has had issues, might have affected bot
 * 12:03:55 #startmeeting horizon
 * 12:04:12 Yeah, the bot isnt in channel.
 * 12:04:40 Right, lets continue anyway.
 * 12:05:10 Only notice is a reminder about deadlines
 * 12:05:25 2 weeks today
 * 12:06:00 Until M-3 releases. We need to make sure bps are complete and ready for review. Start pestering cores if you need to.
 * 12:06:22 yay, pestering cores \o/
 * 12:06:32 Any other notices before we move on to the agenda?
 * 12:06:43 yay IRC has let me into the meeting!
 * 12:07:32 #link https://wiki.openstack.org/wiki/Meetings/Horizon#Agenda_for_2016-02-17_12_UTC
 * 12:08:00 #topic d_o_a stable releases for kilo/liberty
 * 12:08:10 Urgh none of this is going to work is it.
 * 12:08:20  :-)
 * 12:08:26 mrunge: You're up :)
 * 12:08:44 uhm, on a call currently
 * 12:08:59 itxaka
 * 12:09:00 ?
 * 12:09:02 yeah
 * 12:09:28 itxaka, can you speak about the agenda items?
 * 12:09:31 basically regarding the patches linked in the agenda, tsufiev showed concern on the release timing for them
 * 12:09:46 and its a concern that we should all share
 * 12:10:03 itxaka, me?
 * 12:10:06 doa should make a stable release for kilo and liberty
 * 12:10:40 itxaka, ah, got it
 * 12:10:44 yes, I did :)
 * 12:10:45 and then a horizon liberty/kilo release should also follow with a new constraint on doa version to avoid any issues
 * 12:12:50 basically a horizon patch needs a specific new doa version with some backports already merged or it will introduce a known bug
 * 12:13:20 Sounds reasonable
 * 12:13:35 this reads to me like: release a now doa version for kilo, then increase global requirements and then finally patch horizon
 * 12:13:36 so Im guessing release new doa version for kilo/liberty -> bump the requirements for doa in horizon kilo/liberty -> release new horizon version for kilo/liberty
 * 12:14:42 I dont have it very clear how the release process works and so on, so thats the main concern for me
 * 12:14:43 does anyone of you have other patches in the queue for doa in kilo/liberty?
 * 12:15:06 itxaka, either david-lyle or I should take care of that
 * 12:15:08 Best people to speak to are david-lyle and lhcheng
 * 12:15:52 releasing the doa version should be no problem thanks to a david-lyle patch that fixes backwards compatibility https://review.openstack.org/#/q/topic:bug/1526572
 * 12:15:57 worst thing with releases is, process changes from release to release
 * 12:16:40 As as we're careful, I don't imagine there should be any huge issues. It's just a stable bugfix release.
 * 12:16:41 https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release
 * 12:16:51 famous last words...
 * 12:17:40 I'd be tagging doa release tomorrow then, if nothing else comes up
 * 12:18:11 I think the workflow of doa -> bump reqs in horizon -> horizon should alliviate any concers tsufiev ?
 * 12:18:44 itxaka, no, just a little note: bump reqs in openstack/requirements, not in horizon
 * 12:19:01 then proposal bot will propose a requirements patch into horizon
 * 12:19:35 sounds good to me
 * 12:20:13 mrunge, this affects the liberty branch as well, patches are all merged in liberty (doa and horizon)
 * 12:20:26 ack
 * 12:21:47 That's the only agenda items
 * 12:22:00 So: open discussion
 * 12:24:20 Anyone have any topics? Or we can have some time back :)
 * 12:24:49 masco?
 * 12:24:52 sigh
 * 12:25:55 hum, I disappeared for a bit there
 * 12:25:55 hope I didn't miss anything
 * 12:26:00 not really, r1chardj0n3s
 * 12:26:02 Nothing much
 * 12:26:16 Anything you wanted to discuss? Otherwise I'm gonna call it
 * 12:26:22 might be worthwhile reminding folks of https://etherpad.openstack.org/p/horizon-mitaka-midcycle
 * 12:26:28 call it then...
 * 12:26:43 reckon we might have a busy enough few days just trying to move code thru that's in play
 * 12:26:52 but just in case there's something you'd like to talk about
 * 12:27:02 (like angular patch size ;-)
 * 12:27:03 Yeah, I think we'll be focusing on paired coding and reviews it seems
 * 12:27:16 oh, would it be possible to loop external folks in to midcycle?
 * 12:27:24 also, there's a global bugbash coming up
 * 12:27:48 https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka
 * 12:27:49 angular patch size is indeed a concern of mine
 * 12:28:08 thanks robcresswell
 * 12:28:20 Good point. So this is very similar to our Horizon bug days
 * 12:28:33 feel free to pop over to Sydney and smash some bugs with us ... or go somewhere more local ;-)
 * 12:28:43 It would be good to get involved in the bug day. I'll be at the London location for at least a couple of the days
 * 12:29:14 robcresswell: say hi to Alex, who just joined the London office from Brisbane. She says it's cold over there. Who'd have thought.
 * 12:29:48 Ha, bad decision :p
 * 12:30:06 anyway, I don't have anything further, thanks
 * 12:30:23 going to bed before midnight sounds nice
 * 12:30:31 masco, you had something to discuss?
 * 12:30:50 https://review.openstack.org/#/c/255854/#
 * 12:31:10 mrunge, https://review.openstack.org/#/c/255854/ i need ppl opinion on this
 * 12:31:22 oh you are faster then me
 * 12:31:33 hr hr hr
 * 12:31:56 with that being said, I have to leave, unfortunately :P
 * 12:32:24 masco: Just reading
 * 12:32:52 it was about to collect feedback, thoughts etc.
 * 12:33:03 it seems to be a good addition, but some disagreement on implementation
 * 12:34:00 Yep reading comments
 * 12:34:15  David's suggestion seems good to me - does somebody not like that?
 * 12:34:23 masco, btw, what are your further plans on https://review.openstack.org/#/c/261930/ ?
 * 12:34:32 i hope performance wise there will not be much problem
 * 12:35:24 tsufiev, i think instead of deleting the field just hiding will help. am i right?
 * 12:35:47 masco, yes, should be a good approach
 * 12:35:53 since integration needs the shared field
 * 12:35:56 * tsufiev wonders why he didn't think about it
 * 12:36:11 ok will submit a patch for that
 * 12:36:17 masco, awesome :)
 * 12:36:30 tsufiev, :) even i too got this today
 * 12:36:31 Er, why is an individual user get memoized?
 * 12:36:48 Just scanning.
 * 12:37:38 I mean this seems like the memoized part is irrelevant if you're making multiple individual calls
 * 12:37:47 the id would change, no?
 * 12:38:07 robcresswell, can change
 * 12:38:25 i mean for different users
 * 12:38:59 It seems like it would be poor peformance would it not? just making api calls for each user
 * 12:39:05 As David noted.
 * 12:39:40 yes, if each user is different
 * 12:39:49 I guess it depends on no. of users per instance. Hmm..
 * 12:39:51 but practically it won't
 * 12:40:00 Yeah, it shouldnt be huge.
 * 12:40:28 yes
 * 12:40:39 so no worry for performance ;)
 * 12:41:17 Better speak with david then :)
 * 12:41:46 robcresswell, sure. thanks. please add your points on it.
 * 12:42:06 it will help for future reference :)
 * 12:44:04 Anyone else with discussion points?
 * 12:44:09 masco: Sure
 * 12:45:41 We'll end the meeting there, have 15 mins back :)
 * 12:45:54 i don't have anything specific. but i just want request the core to review my QoS patches :)