[07:33] <duflu> alf__: Is glmark2 designed to finish in a fixed time or vary according to GPU power?
[09:07] <alf__> duflu: fixed time (test parameter 'duration' default is 10 seconds)
[09:07] <duflu> alf__: Right, so a slow machine won't take it over an hour then
[09:08] <alf__> duflu: right
[09:32] <duflu> Remind me not to try and fix bugs so much. Fixing the fixes takes so much time that the feature development halts :)
[09:33] <alan_g> Just don't put the bugs in to start with
[09:34] <duflu> alan_g: None are mine (?). I'm trying not to victimize their creators
[09:34] <duflu> Mostly not mine
[09:34] <alan_g> Indeed, we all review the MPs
[09:35] <duflu> Oh and then some devious test reboots my phone
[09:36] <duflu> alan_g: I remember you suggested making people responsible, back at the sprint. I had thought the same before. The real issue is the person desiring a fix the most is not usually the person who broke it
[09:41] <alan_g> I think people should be aware of how they broke something so that they can learn. But one can't be made responsible one has to be it.
[09:44] <duflu> OTOH, if someone is a repeat offender, we would be wise to throttle them with bugfix tasks instead of feature development
[09:44] <duflu> But that would be mean too
[09:45] <duflu> More phone testing...
[09:56] <duflu> alan_g: OK I can reproduce the GLMark2Test hang. It's a visible freeze. Will need to continue tomorrow
[09:57] <duflu> Visible on mako
[09:57] <alan_g> duflu: that's great - I couldn't reproduce (admittedly I didn't spend very long on it)
[09:58] <duflu> alan_g: I suspect we're not matching up number of buffer replies with number of requests. Both server and client are starved and idling
[09:59] <alan_g> Then you've got processes to poke around in? Even better.
[10:00] <alan_g> I'll be glad to see that one gone
[10:00] <duflu> alan_g: Yeah. Annoyingly seems related to what I'm fixing, but more needs fixing obviously
[10:02] <alan_g> duflu: hopefully that means there will be a unified fix that will be obviously correct. (Once you've thought of it.)
[10:02] <duflu> alan_g: Or many
[10:02]  * alan_g hopes not
[10:03] <duflu> Oh it's going to be a bug fix week
[10:05] <duflu> alan_g: Can you track down any more MPs that made it worse?
[10:06] <duflu> Although I've got two that do it reliably
[10:07] <alan_g> I've not noticed any others. But I'll keep track.
[10:08] <duflu> Hmm, framedropping policy has moved into GlibMainLoop recently
[14:22] <AlbertA> ogra_: the mir release is stuck in proposed: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[14:22] <AlbertA> http://pastebin.ubuntu.com/9250453/
[14:23] <AlbertA> ogra_: it looks like ubuntu-touch package has a dep on  libmirplatform3driver-android
[14:23] <AlbertA> ogra_: and looking at the README it seems it is based on the seeds: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/ubuntu-touch-meta/vivid/view/head:/README
[14:24] <AlbertA> ogra_: any ideas on how to move forward?
[14:25] <ogra_> by dropping it ;)
[14:26] <ogra_> its a bit awkward that we have to update the seeds for such a change ... that means new -meta packages for every ABI bump you guys do
[14:26] <ogra_> would be nicer to have a higher level libmir meta package that the seed could depend on
[14:27] <AlbertA> ogra_: right that's why this new mir release introduces mir-graphics-drivers-android
[14:27] <ogra_> (similar to linux vs linux-image vs linux-image-$(uname -r)
[14:27] <ogra_> ah, right, so lets land this then :)
[14:29] <AlbertA> so do we manually modify the dep lists for ubuntu-touch and land it together with the mir release?
[14:30] <AlbertA> ogra_:^
[14:30] <ogra_> no
[14:30] <ogra_> ubuntu-touch-meta gets generated from the seeds ;)
[14:31] <AlbertA> ogra_: ok
[14:31] <ogra_> i just merged your seed change ... takes a bit to generate the package
[14:31] <ogra_> i'll upload asap
[14:31] <AlbertA> ogra_: ok thanks!
[15:24] <alan_g> alf__: I'm looking at MirScreencastTest and thinking that the tests that depend on the mock_screencast are really integration tests. (And that the remaining tests don't really prove the feature.) Do you concur?
[15:24] <alf__> alan_g: looking
[15:31] <alf__> alan_g: I mostly agree. This (like other tests) would like to be true end-to-end tests, but unfortunately that's not possible with our current CI infrastructure.
[15:33] <alan_g> yes
[15:34] <alf__> alan_g: Also what is an acceptance vs integration tests in our current architectur is somewhat fuzzy. The "hexagonal architecture" definition of acceptance vs integration is the clearest I have encountered.
[15:34]  * alan_g goes to google
[15:36] <alf__> (hexagonal == ports and adapters)
[15:37] <alan_g> From a quick skim this looks like what I intended to describe at the initiation sprint
[15:42] <alf__> alan_g: Makes sense. It's also what the example in the GOOS book finally organically ends up with. Here are some nice diagrams from one of the authors: http://www.natpryce.com/articles/000772.html
[15:43] <alan_g> yep
[15:44] <alf__> alan_g: I like that acceptance tests (tests again the domain model) are different from end-to-end (system) tests.
[15:47] <alan_g> Sure. And it does fit with our classification. (What system tests we have are in benchmarks or examples and are not very good at reporting pass/fail)
[15:48] <alan_g> Anyway, for the current instance, you're happy if I shuffle most of the tests over to integration tests?
[15:50] <alf__> alan_g: Sure. If we can easily change some of them to remain in the acceptance tests (and it makes sense to do so), then I would prefer that of course.
[15:52] <alan_g> I'm taking reliance on mock_screencast (as opposed to having it around by accident) as the discriminator.
[15:53] <alf__> alan_g: Moving them will create some acceptance test gaps (e.g. for the mir_screencast api), but let's fix them properly.
[15:54] <alan_g> It just makes the gap more visible
[16:01] <alf__> alan_g: The MirScreencast test in particular could be probably made to work as acceptance test, if we use our MockGL/EGL infrastructure, which makes sense since EGL/GL is our integration point. We don't have an interface for GL/GLES but we can just use the link-time seam as usual.
[16:02] <alf__> alan_g: ... or introduce an interface for it
[16:03] <alan_g> Yes, but I don't want to take that on right now
[16:05] <alf__> alan_g: Understood.
[17:09] <AlbertA> greyback_: mir has released, so no lock on qtmir anymore :)
[17:09] <greyback_> AlbertA: yay, thanks
[19:49]  * DalekSec waves to olli_.
[19:52] <olli_> camako, DalekSec is representing xubuntu and was helping to gather some xmir compatibility test results back in the day
[19:52] <olli_> camako, he had a question if http://unit193.net/wiki/doku.php?id=wiki:mir is still of help
[21:06] <camako> olli_, first time I'm seeing it... It could be useful if it were up to date.