16:01:51 <david-lyle> #startmeeting Horizon
16:01:52 <openstack> Meeting started Tue Sep 16 16:01:51 2014 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:55 <openstack> The meeting name has been set to 'horizon'
16:02:03 <jrist> o/
16:02:06 <tmazur> hello o/
16:02:06 <david-lyle> Hello everyone
16:02:08 <asahlin> Hello
16:02:09 <jgravel> hi
16:02:10 <TravT> o/
16:02:13 <doug-fish> hi
16:02:13 <gary-smith> hi
16:02:13 <woodm1979> o/
16:02:15 <rhagarty> hello
16:02:15 <rdopieralski> hi
16:02:24 <tsufiev> hello
16:02:40 <crobertsrh> hello/
16:03:03 <david-lyle> #topic RC-1 status
16:03:20 <david-lyle> #link https://launchpad.net/horizon/+milestone/juno-rc1
16:03:39 <david-lyle> All 7 FFE related blueprints have merged \o/
16:03:45 <pawels> cool
16:03:49 <gugl> hi
16:04:09 <TravT> \o/
16:04:12 <david-lyle> there is some minor cleanup related to a couple that is being targeted with bugs
16:04:16 <pawels> thanks !
16:04:48 <amotoki> hi
16:05:01 <david-lyle> I saw this morning that amotoki is targeting the neutron L3 HA work with a bug
16:05:13 <david-lyle> so we'll still get that in as well
16:05:27 <amotoki> david-lyle: I just upload the review too.
16:05:49 <david-lyle> amotoki: excellent
16:06:08 <david-lyle> does it require a client change or is this all server side?  I haven't looked at the patch yet
16:07:02 <david-lyle> The lone critical defect we have is still in progress, currently the Horizon tempest test is disabled in the gate
16:07:04 <amotoki> david-lyle: it doesn't require new client release and the server side change in neutron has been merged.
16:07:17 <david-lyle> https://bugs.launchpad.net/bugs/1345955
16:07:21 <david-lyle> amotoki: great
16:07:29 <david-lyle> I like it when it's easy
16:08:10 <david-lyle> I have a devstack patch up to move compression/compilation offline, once that merges, we'll reenable the Horizon tempest test
16:08:35 <david-lyle> All the highs have owners, spare 1
16:09:36 <david-lyle> #link https://bugs.launchpad.net/bugs/1282089
16:09:41 <amotoki> I am not sure why the frequency of the failure became high recently (especially this week). is there any changes in our dependencies?
16:09:58 <david-lyle> amotoki: the bug was not properly characterized
16:10:20 <david-lyle> better definition late last week, meant recheck number increased
16:10:28 <amotoki> yes, I tried to identify, but could not so far.
16:11:01 <david-lyle> this week is puzzling that we would still be seeing it
16:11:29 <TravT> david-lyle: the bugs you filed on the aggregates and flavors metadata also is there on images.  Bug is filed, assigned, and ready for review.  Just need you to add to rc-1.  https://bugs.launchpad.net/horizon/+bug/1370061
16:12:02 <david-lyle> TravT: done
16:12:08 <TravT> thx
16:12:42 <david-lyle> Later this week we'll need to decide what is truly critical for RC-1
16:13:19 <david-lyle> Then work toward RC-1 from that list
16:13:54 <david-lyle> But I plan on at least a week before trying to finely target RC-1
16:14:34 <david-lyle> Once RC-1 is closed, master will open soon after for Kilo work
16:14:43 <david-lyle> Any questions on RC-1?
16:14:50 <doug-fish> david-lyle: so how to we decide what goes in to RC-1?
16:15:05 <doug-fish> I'm sure every thing I've touched is critical; I'm mostly asking for other people.  :-)
16:15:08 <amotoki> TravT: bug 1369678 and bug 1370061 are duplicated?
16:15:24 <TravT> amotoki: let me look
16:15:38 <david-lyle> doug-fish: for the next week, most fixes, beyond that just things you would not ship without
16:16:15 <doug-fish> david-lyle:  ok sure, and if I require a fix in order to ship I just message you and we sort out if it goes on the list?
16:16:15 <david-lyle> important broken functionality, large performance issues, etc
16:16:24 <david-lyle> yes
16:16:29 <doug-fish> super.  Thanks!
16:16:37 <david-lyle> if we find something after RC-1, we open RC-2
16:16:59 <david-lyle> eventually we run out of time, of course
16:17:03 <TravT> amotoki: no they aren't duplicate.  There is a similar issue with exception handling in both of them.  just one affects flavors and the other affects imaes.
16:17:16 <david-lyle> I don't currently see anything we couldn't release without
16:17:20 <amotoki> TravT: got it.
16:17:48 <david-lyle> Agenda for today
16:17:56 <asahlin> So if we have defects  that are marked RC-1 and fixes are available..  They should go in
16:18:10 <asahlin> correct
16:18:15 <amotoki> As usual, I would like to propose a cleanup/import translations.
16:18:37 <david-lyle> asahlin: yes
16:19:02 <david-lyle> amotoki: how far out are we on translations?
16:19:03 <amotoki> The situation changes from Icehouse release because translation import is now done automatically until RC1 is cut.
16:19:32 <david-lyle> amotoki: we could have an RC-2 just for translation, if need be
16:20:03 <amotoki> david-lyle: they don't have an exact date now. RC-2 would be great.
16:20:36 <amotoki> some input from horizon is really helpful. do you have any planned date?
16:21:45 <david-lyle> amotoki: I'd like to target the 25th for RC-1
16:22:17 <david-lyle> if we don't have anything critical on the 23rd, I'd be happy to close RC-1 then as well
16:22:52 <david-lyle> Additionally, I need to release openstack_auth this week
16:23:06 <amotoki> david-lyle: thanks. I think it is no problem. IIRC the target discussed in I18N meeting is around 25th.
16:23:27 <david-lyle> amotoki: that should line up well then
16:24:03 <david-lyle> #link https://wiki.openstack.org/wiki/Meetings/Horizon
16:24:18 <david-lyle> #topic JS Best Practices
16:24:27 <asahlin> I wanted to bring some attention to the JavaScript best practices documentation which is out for review, https://review.openstack.org/#/c/117595/.
16:24:39 <asahlin> I think that this documentation is beneficial and necessary especially as we have more and more client side coding.  Hoping it can get some more review attention.
16:25:32 <asahlin> And to thank those who have already given their feedback, its been valuable.
16:25:50 <david-lyle> asahlin: now that the FFEs are in, more reviews will move back to bugs, docs and testing
16:26:23 <asahlin> great, that is what I was hoping.
16:26:23 <david-lyle> I agree this effort is valuable and lack of reviews is not an indication of lack of support, just release mechanics
16:26:41 <asahlin> One part of the documentation that I haven't seen any review comments on is the JSHint options recommended for your development environment.    It would be great to get some feedback agreeing or disagreeing with the proposed options.  Once we have agreement on the options we want, the next question is if we want to integrate / enforce those options during the continuous builds?   Or have that only as a development tool.
16:27:35 <david-lyle> I think if we're going to set a standard, we'll want to use the gate to enforce it
16:27:42 <tqtran> I think once everyone agrees, we should make it part of the continuous builds
16:28:11 <tqtran> we already have jshint running, why not add a few more options? =)
16:28:26 <asahlin> agreed.
16:28:32 <david-lyle> we aren't the best at self-policing
16:28:48 <david-lyle> as shown when our flake8 stopped running for a while
16:29:26 <david-lyle> asahlin: anything else on this for now?
16:29:38 <asahlin> nope that was it
16:29:43 <david-lyle> thanks!
16:29:46 <amotoki> /FYI/ more readable version of the document is generated automatically and avaialbe at the result of "gate-horizon-docs".
16:30:02 <amotoki> perhaps most of you are aware of it :-)
16:30:24 <david-lyle> #topic Summit Session Planning (david-lyle)
16:31:12 <david-lyle> So as I mentioned in the last meeting, the topic proposal tool is not making an appearance this cycle and instead we'll be using an etherpad, much like we did last cycle
16:31:21 <david-lyle> #link https://etherpad.openstack.org/p/horizon-kilo-summit
16:31:40 <david-lyle> has been set up for those purposes with a few sample topics I included
16:31:58 <david-lyle> we're still a month and a half out, so no hurry
16:32:11 <david-lyle> but feel free to add your topics there
16:33:11 <david-lyle> there will also be scheduled and unscheduled time, when we start determining the final topics, we'll need to determine how the topics best fit into that
16:33:34 <david-lyle> questions?
16:34:14 <david-lyle> #topic Discuss potential changes to the blueprint process (david-lyle)
16:34:43 <david-lyle> So the blueprint process for Horizon worked fairly well when the community was smaller
16:35:12 <david-lyle> was the horizon community has grown \o/ the process is having a tough time scaling
16:35:34 <david-lyle> I want to start the discussion on how to improve the process
16:36:00 <david-lyle> currently we have a lot of blueprints that have one or two sentences as a description and that's it
16:36:17 <david-lyle> granted, for some items that is almost enough
16:36:51 <david-lyle> but I'd like to have a more formalized template in the blueprint as to what is covered by the blueprint
16:37:34 <david-lyle> Things like UX design links, doc impacts, dependencies in other projects, etc
16:38:14 <david-lyle> I'm not really in favor of the specs repo process mostly because I think it creates a review bottleneck, but we need to get more formalized in our process
16:39:18 <david-lyle> with that greater formality, I'd like to actually start using the approval states as a proper indicator of where this blueprint stands
16:39:25 <david-lyle> and only merge approved blueprints
16:39:44 <david-lyle> I don't think the blueprints should bottleneck on the PTL, but the core can continue to approve
16:40:07 <david-lyle> of course, I'm open to suggestions
16:40:26 <david-lyle> but I think the current wild-west of BPs in Horizon is not sustainable
16:40:46 <amotoki> Huge +1. At least the design direction must be clear when it is approved.
16:41:05 <rdopieralski> I would love to see the process well defined and documented
16:41:09 <jpomero> is the idea to just come up with a template that all blueprints should use?
16:41:11 <asahlin> I am newer to the community, and haven't been around / involved with a blueprint creation cycle...  but I agree with everything your saying +1
16:41:25 <david-lyle> jpomero: yes, essentially
16:41:40 <david-lyle> even if N/A is the content of the section
16:41:55 <jpomero> yeah seems like a good idea
16:42:03 <david-lyle> but things like cross-project dependency tracking puts a huge burden on reviewers
16:42:25 <david-lyle> I'll create a formal proposal and hopefully we can discuss it next week
16:42:45 <gary-smith> this sounds like a practical approach, and preferable to the specs repo formality
16:43:18 <david-lyle> I don't want the process to be so formalized as to block progress, so I'm hoping for balance
16:43:44 <david-lyle> The last part of this discussion was around planning bps in cycles
16:43:58 <TravT> a template would be great... agree that the specs repo process is kind of painful.
16:44:10 <gugl> not only need a process doc, but also need a good example, so everyone can follow
16:44:34 <david-lyle> gugl: I agree, I will provide that as well
16:44:37 <amotoki> I think discussion on blueprint whiteboard works so far.
16:45:04 <david-lyle> amotoki: yes, I like the discussions and want to keep that
16:45:36 <jacalcat> There has been some work to create design patterns, which would be good to point to as part of the template. Also, some standards around the type of wording that appears in the UI.
16:46:01 <david-lyle> I should probably check on the current status of storyboard as well
16:46:19 * krotscheck perks up
16:46:36 <rbertram> Do we need UX approval of blueprints?
16:47:30 <jacalcat> I think that would help.
16:48:00 <david-lyle> rbertram: I think that will depend on the nature of the blueprint, but I would certainly be in favor of that, I just don't want to block on the limited UXers we have
16:48:12 <amotoki> I believe horizon reviewers have good UX perspective to some extent.
16:48:31 <rbertram> david-lyle: agreed - and as you said before, N/A is often fine
16:48:59 <asahlin> rbertram:  I think that more involvement with UX would be good.
16:49:09 <david-lyle> I'll see what the UX team is willing to sign up for, I think lblachard is out for a while
16:49:23 <david-lyle> *lblanchard
16:49:55 <david-lyle> so needs more investigation as to level of UX input
16:49:59 <gugl> david-lyle, UX team is folks in #openstack-ux?
16:50:05 <david-lyle> gugl: yes
16:50:10 <gugl> k. tks
16:50:18 <david-lyle> I'll ping them offline
16:50:49 <jacalcat> David, please include me.
16:50:49 <david-lyle> krotscheck: Think I just need to kick the tires again :)
16:50:57 <david-lyle> jacalcat: absolutely
16:51:23 <david-lyle> I'll use the public instance
16:52:08 <david-lyle> we'll talk planning and scheduling later
16:52:14 <david-lyle> #topic Open Discussion
16:52:19 <david-lyle> bring it
16:52:24 <david-lyle> :)
16:52:35 <tqtran> lol no more wild west stand offs?
16:53:01 <david-lyle> tqtran: not so fast
16:53:01 <amotoki> we have many existing blueprint with unknown status... it is a good time to clean-up.
16:53:23 <david-lyle> amotoki: I agree
16:55:48 <amotoki> I am not sure what process or criteria is good to clean up but new blueprint process will make it clear :-)
16:56:46 <david-lyle> I'm not sure if just marking the obsolete would help
16:57:14 <david-lyle> then if people are interested, re-propose the blueprint with the appropriate template
16:57:41 <david-lyle> I don't think there's a way to delete bps
16:58:01 <david-lyle> that said, just because someone is not working on something doesn't mean it's not a good idea
16:59:04 <amotoki> yes. most bp proposals are good feature candidates, but blueprints require someone who work on them. It is a balance.
17:00:35 <david-lyle> Looks like time is up. Thanks everyone for all your hard work on RC-1 so far. Have a great week!
17:00:39 <david-lyle> #endmeeting