[14:57] <DavidChen> good morning/evening everyone
[14:57] <seb128> hey
[14:58] <bafu> DavidChen: hi
[14:58] <mlankhorst> g'day mate
[14:58] <DavidChen> bafu~~~  you are here!
[14:59] <bafu> DavidChen: yeah, good to see u ha
[15:03] <tjaalton> seb128: so, when do I get the hangout link? :)
[15:04] <seb128> tjaalton, should be on summit I think
[15:04] <mlankhorst> oh we now have a pic of seb128, wee
[15:05] <seb128> tjaalton, mlankhorst: /msg it to you
[15:05] <seb128> please share with others that should join
[15:06] <seb128> tjaalton, coming?
[15:06] <tseliot1> seb128: me too, please
[15:06] <tjaalton> huh, didn't have the plugin installed
[15:06] <seb128> tjaalton, way to be ready :p
[15:06] <mlankhorst> what a massive lag o.O
[15:06] <seb128> if anyone else, please ping me for the link
[15:07] <blitzkrieg3> hi
[15:08] <kgunn> seb128: if its light, i'll take the link
[15:08] <tkamppeter__> hi
[15:08] <seb128> kgunn, https://plus.google.com/hangouts/_/03d384463476f28c0e4ef7a1cbfd964aa4abcab5?authuser=0
[15:08] <seb128> let's just share it on the channel
[15:08] <seb128> I doubt people will abuse it ;-)
[15:09] <olli-uds> mlankhorst: should be just on the left
[15:09] <mlankhorst> what a lag o.O
[15:09] <liuxing> hello  everyone
[15:11] <seb128> shrug, I'm getting what I say a minute ago coming now
[15:11] <seb128> said
[15:11] <mlankhorst> yeah there's a lot of lag
[15:12] <seb128> ok, better, I had the summit playback video in a tab
[15:15] <ppisati> aren't we dropping panda images? so why do we care about X on omap?
[15:15] <rsalveti> mlankhorst: so we'll be maintaining 2 different versions of the x stack?
[15:15] <rsalveti> ppisati: not sure if we're indeed officially dropping for this cycle already
[15:15] <mlankhorst> rsalveti: yeah, pandaboard just won't get updates
[15:15] <olli-uds> how big is the diff/change
[15:16] <olli-uds> for Unity
[15:16] <mlankhorst> olli-uds: small
[15:16] <rsalveti> mlankhorst: how will you manage 2 different xorg versions there?
[15:16] <mlankhorst> rsalveti: I explained on the stream, it's a bit laggy, maybe it came through now :)
[15:16] <rsalveti> ppisati: problem is that it doesn't work for touch either, no updates for the drivers even at the android side
[15:17] <ppisati> rsalveti: my last info was that we were dropping omap4 images
[15:17] <ppisati> rsalveti: R was the last one
[15:17] <rsalveti> kgunn: you should help us getting a newer driver for panda :P
[15:17] <rsalveti> ppisati: right, thought about the same, just didn't hear an official statement
[15:17] <kgunn> rsalveti: i wish
[15:17] <olli-uds> apw: we are here ;)
[15:18] <olli-uds> apw: kgunn: it will be Unity 7.x (nux) on a pure X stack
[15:19] <apw> olli-uds, i assume that is the same whether mir is underneath as a system compisitor or not
[15:19] <olli-uds> apw good catch
[15:24]  * apw seems to have lost the stream
[15:25] <olli-uds> kgunn:do we need anything specific for/from X?
[15:26] <kgunn> olli-uds: don't think so...other than stability :)
[15:26] <kgunn> olli-uds: i'll follow up offline, but my understanding
[15:26] <kgunn> is that any extension discussions we've had are relatively x version indep
[15:31] <bregma> touch is just very complicated and there's not a lot of usage
[15:32] <bregma> we've been working on it for 3 years, it's still not quite right
[15:32] <jmleddy> yeah that bug is a pita
[15:33] <jmleddy> I think we will need 12.04 too...
[15:33] <smagoun> +1....OEMs are expecting to ship a lot more Ubuntu systems (laptops, all-in-ones) with touchscreens. We need to make sure we have solid touch support in the OS
[15:34] <smagoun> We need a solution for 12.04, that is correct - OEMs are shipping 12.04, and will shift to 14.04 later in 2014
[15:38] <jmleddy> tjaalton: what about prime integration into lightdm so that it "just works"?
[15:38] <ritz__> I have an older radeon card with my laptop, open for testing
[15:40] <jmleddy> tseliot1: script should be in the distro though
[15:40] <mlankhorst> any other questions?
[15:40] <seb128> mlankhorst, I seem to lag, do we need a W.I for the unity/barrier changes?
[15:40] <tseliot1> jmleddy: definitely, it won't live in a ppa
[15:40] <jmleddy> mlankhorst: that's a separate issue though...
[15:41] <jmleddy> tseliot1: okay, just wanted to make sure it was covered
[15:41] <jmleddy> I want that part fixed as well :)
[15:41] <tseliot1> good
[15:41] <smagoun> lots of lag here I think....is there some documentaion on how mir will handle hybrid gfx and switching GPUs?
[15:41] <tkamppeter__> What about wireless screen connection WiDi etc?
[15:42] <kgunn> smagoun: an advanced topic for mir team, we've got on the list (captured in our convergence blueprint)
[15:42] <kgunn> smagoun: but something we haven't spent time on
[15:43] <jmleddy> advanced as in 14.04?
[15:43] <tkamppeter__> Any idea about wireless screen connection?
[15:44] <tjaalton> tkamppeter__: what's that?
[15:44] <kgunn> jmleddy: advanced as in convergence (i say that as in its a deliverable)
[15:44] <jmleddy> okay
[15:44] <tjaalton> jmleddy, smagoun: yep, we'll get the touch fix for 12.04.4 at the latest :/
[15:44] <kgunn> jmleddy: admittedly, we have a long row to hoe before getting to topics like simultaneous multi gpu support
[15:45] <tkamppeter__> tjaalton: similar to AirPlay, you have a video (also live stream) on your laptop and want to forward it to the TV, or even get your desktop on the TV, but wireless.
[15:45] <seb128> mlankhorst, did you see my question earlier? "do we need a W.I for the unity/barrier changes?"
[15:45] <kgunn> tkamppeter_: as for mir, wifi display should just be another display
[15:46] <jmleddy> kgunn: okay
[15:46] <tkamppeter__> kgunn: is there some active work done on that under Linux?
[15:46] <mlankhorst> seb128: that was probably intended for precise, for saucy we'll just upload unity together with the new xserver
[15:46] <kgunn> tkamppeter_: altho, there is a question of having proper rtp plugin support (e.g. miracast)
[15:47] <kgunn> tkamppeter_: which might be a question for foundations team
[15:47] <tjaalton> i guess widi has drm written all over it, and no drivers for linux
[15:47] <seb128> mlankhorst, "just upload unity", is the patch to support the protocole change done or does it need an assignee/workitem?
[15:47] <tjaalton> seb128: it's done, but not upstream yet
[15:47] <seb128> ok
[15:47] <kgunn> tkamppeter_: wrt active work on linux, android has this actually built in today
[15:47] <kgunn> as part of jellybean
[15:48] <mlankhorst> seb128: it's a small change, if you use the x1.14 ppa on raring you'll have the updated unity for raring.
[15:48] <seb128> ok
[15:48] <tkamppeter__> kgunn: will this code move into X, MIR, Wayland for desktop Linux? Perhaps we will have wireless projectors in the future.
[15:49] <tkamppeter__> kgunn: and Ubuntu Touch would also be great to connect to Monitor/Keyboard/mouse completely wireless/
[15:50] <mlankhorst> tkamppeter__: bluetooth :-)
[15:50] <mlankhorst> or write something that uses the kernel uinput module if you want to go crazy
[15:50] <tkamppeter__> mlankhorst: for keyboard/mouse it works, but for screen BT has probably not enough bandwidth.
[15:50] <kgunn> tkamppeter_: all the wifi aspect should be up to a hw abstraction layer, making it just look like a new screen has appeared
[15:50] <mlankhorst> yeah but nothing does
[15:51] <kgunn> tkamppeter_: so it shouldn't be in mir/wayland/x
[15:51] <mlankhorst> it's 474 megabyte/second
[15:51] <mlankhorst> for 1080p @ 60 fps
[15:51] <tkamppeter__> kgunn: in which part of the OS will this be implemented then?
[15:52] <tkamppeter__> mlankhorst: does Bluetooth that speed? I think WiFi is even not that fast.
[15:53] <mlankhorst> nah ofc not
[15:53] <mlankhorst> but for wireless mouse keyboard it's good enough
[16:06] <seb128> tkamppeter__, there?
[16:06] <seb128> tkamppeter__, your session is starting, hangout url is https://plus.google.com/hangouts/_/14bdba95931d5f848a5321673c459a77f66b9131?authuser=0
[16:06] <seb128> who should be there?
[16:16] <greyback> hey
[19:04] <kgunn> seb128: are you my monitor for mir testing ?
[19:04] <seb128> kgunn, hey, https://plus.google.com/hangouts/_/01715a02682e4a34c409e8ead9999d1194873738?authuser=0
[19:04] <kgunn> thanks!
[19:05] <seb128> kgunn, no robert_ancell?
[19:08] <cjohnston> seb128: could you please add the view link to summit
[19:09] <gema> yeah, or give us the link to it
[19:09] <seb128> cjohnston, sorry, forgot to press the save button
[19:09] <seb128> done
[19:09] <seb128> http://youtu.be/qIj0GcTCXQs
[19:09] <cjohnston> ty
[19:09] <rickspencer3> o/ all
[19:10] <cjohnston> heya rickspencer3
[19:10] <seb128> rickspencer3, hey
[19:10] <josepht_uds> please use your lower third
[19:11] <gema> kevin Gunn talking right now
[19:11] <cjohnston> seb128: kgunn ^
[19:11] <seb128> done for me
[19:11] <cjohnston> seb128: I don't see it
[19:12] <seb128> maybe it takes a bit to apply?
[19:12] <cjohnston> there it is
[19:12] <balloons> delay is killer :-)
[19:12] <gema> there is a bit of lag, indeed
[19:13] <gema> but the comments appear before the video says it, so it is also kind of cool
[19:13] <balloons> gema, lol
[19:17] <gema> tvoss: because the hard drive may have bad sectors,
[19:18] <gema> tvoss: you have hardware interactions, etc
[19:18] <tvoss> gema, which brings me to the question what sigma we are talking about :)
[19:18] <gema> tvoss: if you constrain your testing condition enough, probably not much
[19:19] <plars> assuming that it's going to be the same isn't helpful, running it multiple times will tell you if it is or not though. If the stddev is high, then you know you *really* have a problem. If it fluctuates by a few bytes from one boot to the next, well... I'll let you decide the criticality of that
[19:20] <tvoss> plars, agreed :)
[19:20] <plars> also if you have some corner case that causes the memory to drastically vary once in a while, multiple runs will expose that too
[19:20] <gema> tvoss: I'd like to know what stress conditions you guy define for mir
[19:20] <hikiko-uds> sorry, connection problems :)
[19:20] <gema> tvoss: and what test cases you want to run under those
[19:23] <gema> negative testing and positive testing would be functional, not stress
[19:25] <sergiusens> QUESTIONS: what's the running cadence going to be and at want point in time from "code to in the image" is this going to be run?
[19:26] <gema> how do you know that under stress the system is working?
[19:26] <gema> you need to figure that out
[19:26] <gema> what does it mean the system is working under stress
[19:27] <sergiusens> kgunn: during an MR, during a package build or after an image builds in cdimage
[19:28] <sergiusens> but thomi got it
[19:28] <thomi> \o/
[19:28]  * thomi high-fives sergiusens
[19:29]  * sergiusens hi5s thomi back
[19:35] <sergiusens> tvoss: can't the target MR reviewer take that into account?
[19:36] <sergiusens> tvoss: or do you want to do it during MRs?
[19:36] <gema> if you don't define what a regression is in terms of stress, you are not going to get regressions and you cannot know what makes a test fail
[19:36] <gema> stress tests sometimes don't fail, they just slow everything down
[19:36] <sergiusens> gema: well if it is going to block stuff, it needs to be defined
[19:36] <gema> and how much slow down is bad enough to fail stuff
[19:36] <gema> sergiusens: indeed
[19:36] <gema> sergiusens: we should block submissions on functional testing
[19:37] <gema> lots of stress testing not enough functional doesn't work
[19:37] <gema> imho
[19:37] <kgunn> it seems we've established 24 hours worth of testing is too long
[19:37] <gema> kgunn: one week of stress testing sounds good to me
[19:37] <gema> kgunn: when you don't block submissions on it
[19:37] <kgunn> i don't vote for blocking submissions
[19:37] <sergiusens> well, for stress... it is a special case, where you run and I believe you just need to capture the good stuff and then sit down and analyze
[19:37]  * gema is confused as to what stress testing means here
[19:38] <kgunn> sergiusens: yes
[19:38] <kgunn> mainly before a mobile oem gets his hands on it :)
[19:38] <gema> kgunn: can you put someone to do a test plan, define conditions, document them , publish them for others to know and test further?
[19:39] <gema> kgunn: so that we know where you guys stop testing and where we need to start?
[19:39] <notclive> is there a reason not to do a large stress test for each commit?
[19:39] <gema> notclive: that'd be too slow
[19:40] <gema> it's not too much lag, we can do a run weekly of stress testing
[19:40] <gema> at the distro level
[19:40] <gema> indeed
[19:41] <gema> post-commit
[19:41] <sergiusens> in all honesty, stress is special case, it needs to be in distro or people won't notice it
[19:41] <gema> sergiusens: agreed
[19:42] <gema> kgunn: you should aim at mir not eating all the memory after being used for 2 months
[19:43] <gema> kgunn: which is what is going to happen in real phones
[19:43] <gema> people wont reboot them every day
[19:43] <sergiusens> thomi: exactly, you need to sit down and do a lot of data crunching and figure out what happens
[19:43] <kgunn> gema: never heard that before ;)
[19:44] <gema> tvoss: very good point, defining what health system is and be able to report when things are not looking healthy
[19:44] <gema> tvoss: surely those phones can send emails, right?
[19:45] <gema> ;)
[19:45] <balloons> nightly reboots: shudder
[19:46] <sergiusens> tvoss: phones take 10 minutes
[19:46] <sergiusens> tvoss: if you want to run it in the full os
[19:50] <gema> thomi: doesn't sound easy to me, can you involve us in the review of it?
[19:50] <gema> thomi: so that we can then capitalise in distro QA and do something at the distro level
[19:53] <tvoss> gema, what's your timeframe for getting it wired up in distro testing? would it make sense to go ahead for Mir, and integrate with distro testing over time?
[19:54] <olli> thx everybody
[19:54] <tvoss> thx olli :)
[19:54] <olli> I did the hard part
[19:54] <olli> letting people talk that know their stuff with out interrupting ;)
[19:54] <tvoss> olli, o/