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