13:01:08 <alinefm> #startmeeting 13:01:08 <kimchi-bot> Meeting started Wed Sep 24 13:01:08 2014 UTC. The chair is alinefm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:08 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:01:08 <alinefm> #meetingname scrum 13:01:08 <kimchi-bot> The meeting name has been set to 'scrum' 13:01:26 <alinefm> #info Agenda 1) Status 2) Open discussion 13:01:26 <alinefm> anything else? 13:01:43 <royce> good for me 13:04:00 <alinefm> #topic Status 13:04:00 <alinefm> #info Please provide your status using the #info command: #info <nickname> <status> 13:04:17 <YuXin> #info YuXin Working on defects 13:04:19 <vianac> #info vianac opened a few issues on Github while testing Kimchi for the GA release; tested Kimchi on Fedora 20 according to the test matrix; closed bugs #415, #435, #447 (partially); sent first version of patchset to fix issue #433; closed a bug where the mockmodel was writing actual files on the disk when it shouldn't; reviewed some patches on the mailing list 13:04:44 <wenwang> #info wenwang sent patch that fix bug UI: Pop up errors when log out at "Host" tab 13:05:28 <wenwang> #info wenwang sent patch that fix bug#424 Edit Template, "Disk (GB)" is always changing when select "Storage Pool", user input is missing. 13:06:04 <alinefm> #info alinefm sent patch to fix issues #429, #430, #452, #419 (already merged) 13:06:06 <wenwang> #info wenwang sent patch that fix bug#426 Create 'bridge' network, when no interface available, it popup error. 13:06:38 <alinefm> #info alinefm sent patch to fix issues #417, #437, #432 (waiting for reviews) 13:06:39 <royce> #info royce fixed bug about: fake uri for repo test, rollback in update repo, filter unsupported volumes from disk list for attachment, took sick leave for two days 13:06:52 <wenwang> #info wenwang working on bug fix that edit guest did not refresh volume when storage pool chages 13:06:59 <alinefm> royce, hope you are better now =) 13:07:11 <royce> thanks alinefm 13:07:49 <royce> better, if there are not much things need me, I hope I can go off-line earlier today, can I? 13:08:28 <alinefm> sure! 13:08:45 <royce> The whether in Beijing changes too fast.... Thanks a lot alinefm! 13:08:56 <royce> I mean weather... 13:09:27 <alinefm> just let me share what is coming after 1.3 13:09:56 <alinefm> I have checked all open bugs yesterday night and there are still 10 that would be good to close for 1.3 13:10:10 <alinefm> from those 10 at least 4 have patches on ML 13:10:35 <alinefm> vianac and I will try to get them fixed today 13:10:54 <alinefm> after that, we are ready for 1.3 unless any of you have more concerns 13:10:58 <royce> are there anything I can help alinefm? 13:11:32 <YuXin> any UI bugs left? 13:11:37 <royce> The filter seems not rebased, do I need to rebase it today? 13:11:50 <alinefm> royce, no - the bugs left seems to be easy to solve 13:11:59 <alinefm> royce, it is time to you sleep =) 13:12:06 <alinefm> I will check the filter and rebase for you 13:12:34 <alinefm> YuXin, https://github.com/kimchi-project/kimchi/issues/445 13:12:46 <alinefm> only this one ^that I think it is important for now 13:12:48 <royce> Let me see, you can merge the UI first and I can send the backend tomorrow 13:13:10 <royce> I don't want to leave trouble to you 13:13:12 <alinefm> royce, today is our deadline 13:13:13 <YuXin> I will fix 445 tomorrow 13:13:21 <alinefm> we have to have everything merged today 13:14:22 <YuXin> I do not have the environment to handle 445 noww 13:14:33 <royce> Then I will rebase it today 13:14:43 <YuXin> Alinefm, can you look into 445 today 13:14:47 <alinefm> YuXin, I can do that 13:14:54 <YuXin> many thanks 13:15:02 <alinefm> YuXin, from what I see in the code I just need to move code around 13:15:18 <YuXin> exactly 13:15:46 <YuXin> all the code is there, just re-organize the code and send rtequests ou 13:15:56 <YuXin> send requests out 13:16:22 <YuXin> if the response is not that fast that you feel there is a delay when open the dropdown 13:16:38 <YuXin> try setTimeout 13:16:48 <alinefm> there is the "Searching..." label for that 13:16:58 <alinefm> until get the response 13:16:58 <YuXin> yes 13:17:37 <YuXin> but each time user open the dropdown, he will see "Searching..." 13:18:03 <alinefm> alright - and then we set the peers on response? 13:18:24 <YuXin> and I remember that in a patch review, you found that the /peers request is not response fast, that is why we add "Searching..." 13:18:44 <alinefm> yeap - I remember 13:18:57 <alinefm> any more concerns for 1.3? 13:19:10 <YuXin> so we can use setTimeout to periodically send /peers requests 13:19:35 <YuXin> then we user open the dropdown, there is always a list of peers up to date 13:19:55 <alinefm> how much periodically? 13:19:58 <alinefm> 1min? 13:20:51 <YuXin> how about 10 seconds 13:21:58 <YuXin> or you know that the /peers request will trigger a big workload at backend? 13:22:06 <alinefm> I don't think this information change so frequently 13:22:31 <alinefm> seems a lot of requests that will not provide any new info 13:22:46 <alinefm> do you think send the request on user selection is bad? 13:23:00 <YuXin> now, each time user login, he will definitely get an updated list of peers, is this enough? 13:23:43 <YuXin> if send the request on user selection, user will always see "Searching.." even no new peers are added 13:24:12 <YuXin> if send the request on user selection, I recommend below 13:24:30 <YuXin> 1. when user open the dropdown, send the request 13:24:48 <YuXin> 2. keep the original list peers there before the response is back 13:25:07 <YuXin> 3. At the bottom of the list, add a "Searching more...." 13:25:23 <YuXin> 4. When response is back, update the whole list 13:25:26 <YuXin> is this ok? 13:25:53 <alinefm> I think it is better to clean up the list and only display "Searching..." because a previous peer listed before can not be available anymore 13:26:09 <alinefm> so when the request completes the peer will be removed from list 13:26:15 <alinefm> may cause confusion to user 13:26:49 <YuXin> how long do you think the /peers request will be back in average? 13:28:43 <alinefm> need to check but ~3 seconds 13:28:57 <YuXin> within 3 seconds? 13:29:08 <alinefm> yes 13:29:11 <YuXin> ok 13:29:31 <alinefm> it is not much but causes a delay on UI 13:29:35 <YuXin> just make it "Searching" when user open the dropdown 13:29:43 <alinefm> ok 13:31:07 <alinefm> I will get merged everything today and prepare the release (update changelog, create the packages, update the github.io page, etc) tomorrow 13:31:17 <alinefm> hopefully the announcement will be done tomorrow too 13:31:24 <alinefm> I will send an email to ML as usual 13:31:57 <alinefm> and then it is time to think about next release \o/ 13:32:14 <fnovak> i would err on showing existing list and updating (with searching more ) if that's the case... Even if you wait and update, a sec later the peer could still drop off 13:33:00 <fnovak> seems better than just showing 'searching' 13:33:34 <fnovak> we just need to handle the 'peer no longer available' 13:33:48 <alinefm> fnovak, yeap 13:34:12 <alinefm> when a peer is not available the UI will not be loaded - I think it is a minimal corner case 13:34:23 <alinefm> the UI = the new browser tab 13:35:05 <YuXin> I am ok if it will resonse within 5 secs 13:36:08 <YuXin> if the /peers request takes long to response, when I want jump to a peer that is already there, then I still need to wait 13:37:35 <YuXin> as it is rare to add/remove peers, we are making a frequent operation bad for a rare case 13:37:55 <alinefm> yes 13:38:16 <alinefm> well, seems we have an agreement on it =) 13:39:02 <alinefm> now I'd like to ask everyone to input your ideas in our backlog (https://github.com/kimchi-project/kimchi/wiki/todo-backlog) or send the RFC on ML 13:39:23 <alinefm> so we can have the next release plan soon 13:40:09 <alinefm> I am working with YuXin and wenwang with a new UI design. I will input everything we have on the github wiki so everyone can provide us feedbacks 13:40:55 <alinefm> if we all agree we can start some work on it for next release 13:41:12 <wenwang> Sure alinefm, great 13:42:18 <alinefm> this release will be shorter than the usual due the holidays in the end of the year 13:42:33 <alinefm> but I think we can do great things =) 13:43:21 <alinefm> pvital, ramonn, rotru, royce, vianac, ^ 13:43:23 <alinefm> ok? 13:43:32 <royce> Of course! 13:43:35 <alinefm> (something I think no one is reading me heheh) 13:43:49 <pvital> k 13:43:57 <wenwang> Sure 13:44:33 <royce> I was just rebasing 13:44:52 <royce> now sent, hope it'll reduce your trouble, alinefm 13:45:19 <alinefm> royce, thanks! 13:45:34 <alinefm> anyone has topic for the open discussion section? 13:46:01 <royce> my pleasure, the new UI sounds interesting 13:46:46 <alinefm> royce, yeap! hope we can improve the mobile experience with that 13:48:00 <YuXin1> aline, the new UI has not been contained in the backlog at all, part is already there? 13:49:10 <alinefm> YuXin, we can add it to there and link to the wiki with the screen shots 13:49:21 <royce> :O we are officially going to market now so we redesign the UI? 13:49:32 <alinefm> but of course, for a devel perspective we will need to do the changes by parts to avoid conflicts 13:50:22 <YuXin1> aline, ok 13:50:40 <alinefm> royce, not sure I understood what you meant 13:52:39 <YuXin1> royce, the current UI is not flat(the whole industry is embracing flat design) 13:52:40 <royce> I wonder why we redesign current UI is because Kimchi is going to be widely used by clients and need to look better:) 13:53:28 <YuXin1> the current UI can run on tablet, but it is not responsive at all 13:53:39 <royce> OK 13:53:59 <alinefm> royce, most of changes come from users feedbacks, specially on mobiles 13:54:09 <YuXin1> we need shape the overall UI direction and style which sustain and for us to keep consistecy for long 13:54:22 <royce> I will consult with you guys about responsive UI design:) 13:54:37 <alinefm> I have a couple of links - one minute 13:54:38 <YuXin1> sure 13:56:29 <alinefm> royce, http://colly.com/ 13:56:50 <alinefm> open it in your browser and start re-sizing the browser window 13:56:56 <alinefm> until get a tablet size 13:57:20 <alinefm> it is like magic =D 13:58:46 <alinefm> there are more examples here: http://designmodo.com/responsive-design-examples/ 14:01:05 <royce> Helpful! Thanks alinefm 14:01:13 <YuXin1> good samples, layout adapt base on real screen estate 14:02:38 <alinefm> royce, YuXin1, if you open Firebug and goes to "CSS" tab you can see it is just one HTML and on CSS there are @media to describe the element position according to screen size 14:03:06 <royce> yes! 14:04:52 <alinefm> we are over time now 14:04:56 <alinefm> anything else for today? 14:05:35 <rotru> alinefm; what about the help ? 14:06:22 <alinefm> rotru, did you send a new version? if so, I will review and apply 14:07:21 <rotru> alinefm; I will merge the functions as you asked, but its going to be ugly 14:08:18 <alinefm> we can talk more after the meeting 14:08:19 <rotru> alinefm; also, you said to the get plugin help html file from the configuration file ( [/help] ).... my code makes this not necessary 14:08:52 <alinefm> rotru, why Kimchi should load plugin config? 14:09:11 <alinefm> I mena, in your code Kimchi is responsible to set the help config for the plugin 14:09:14 <alinefm> it is not needed 14:09:30 <alinefm> each plugin has its own config file to be "free of kimchi" 14:10:15 <rotru> alinefm; it is just a convention ... kimchi is not setting anything ... 14:11:33 <alinefm> rotru, if kimchi does need to do anything else than read the plugin config it is doing something =) 14:12:29 <rotru> alinefm; we are going to fall in the same problem as before, plugins and kimchi running from different places ... from git, from rpm installation , etc 14:12:38 <alinefm> can we continue after meeting? I don't want to block people for long time 14:12:48 <rotru> thats ok 14:12:58 <alinefm> rotru, we have discussed to Zheng Zhou to use git-submodule, right? 14:13:29 <alinefm> just one thing before finishing... 14:13:50 <alinefm> I want to thank all of you for the hard and great job for 1.3 14:14:12 <alinefm> without your commitment it would not be possible 14:14:23 <alinefm> so many thanks! 14:14:36 <royce> Thank you alinefm! 14:15:24 <alinefm> #endmeeting