[04:30] <RAOF> duflu: Do you have any suggestions for shorter test names?
[04:30] <RAOF> They're that long because I think they need to be that long to describe what they're testing :)
[04:35] <duflu> RAOF: Not sure. I'm happy to ignore it if the other minor issues are fixed
[04:35] <RAOF> duflu: They are now.
[04:35] <RAOF> (I think)
[04:36] <RAOF> Or, at least, have been thrashed out here (const-ness of make_current, etc)
[07:51] <duflu> Woo, Jenkins is landing things!
[08:17] <RAOF> Oh, wow. Do we really put the { on the next line in *assignments*? Yes, yes we do.
[08:18] <RAOF> That's really silly.
[09:13] <alan_g> anpok_: thanks for fixing cross-compilation!
[09:21] <anpok_> no problem
[09:28] <RAOF> duflu: Those names any better? :/
[09:33] <duflu> RAOF: I will assume yes. They don't stand out as obviously crazy any more. So I closed my eyes and hit Approve
[09:36] <alan_g> duflu: why don't you want to publish the demo_standalone examples?
[09:37] <duflu> alan_g: Because they contain very bad practices of mixing client and server code in undesirable ways
[09:37] <duflu> Hence bad examples
[09:38] <anpok_> why do we have those examples then?
[09:38] <anpok_> if the source is there, people will see and copy from it
[09:38] <duflu> anpok_: Because they pre-date having a rich and functional client+server architecture
[09:38] <alan_g> duflu: http://unity.ubuntu.com/mir/render_surfaces-example.html
[09:38] <duflu> They were necessary to test things earlier in Mir's life
[09:42] <duflu> alan_g: I'm not sure that's a helpful example. Though it does make me think we need better demo-server examples/docs
[09:42] <alan_g> There's nothing wrong with using the server APIs to put stuff on the screen. If we want to set a better example we should improve the code, not hide the executables.
[09:44] <duflu> alan_g: Functionality used by render_surfaces such as setting rotation and using a buffer initializer and examples of things I expect to be eliminated eventually. We shouldn't encourage people to copy that
[09:45] <duflu> Although, if we all agree demos may be removed from the mir-demos package at any time, then I guess it doesn't matter what goes in it
[09:46] <alan_g> duflu: it's inconsistent to have the code and publish it to the website but not put it in the package.
[09:47] <duflu> alan_g: Well doxygen's automagical publishing is something less controllable than packaging :)
[09:47] <alan_g> duflu: I do agree that the code in several examples is less than exemplary.
[09:48] <alan_g> duflu: only because you know the incantations for one and not the other. ;)
[09:48] <duflu> alan_g: True
[09:48] <duflu> And now I have to go sit in traffic. Hurray.
[09:49] <alan_g> Have a good evening!
[10:27] <alan_g> RAOF: you about?
[14:41] <alan_g> kgunn: you've just approved "build-options-for-tests"? Have you co-ordinated putting the changed options into jenkins?
[14:42] <kgunn> uh-oh, alan_g maybe i misunderstood
[14:43] <kgunn> alan_g: got it...i missed alf's comment above duflu's
[14:43] <kgunn> makes sense now
[14:43] <kgunn> thanks for the catch
[14:43] <alan_g> np
[14:43] <alan_g> BTW we're able to land stuff today
[14:43] <kgunn> alan_g: it does seem like we are now passing ci reliably
[14:44] <kgunn> yep
[14:45] <kgunn> alan_g: so...thinking we might be able to promote lp:mir/dev to lp:mir....can i ask for some advice
[14:46] <kgunn> seems our deb change is back about 2 revs
[14:46] <kgunn> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1292
[14:46] <kgunn> should i revert and then reapply ?
[14:46] <kgunn> or just bump again ?
[14:46] <kgunn> thots
[14:47]  * kgunn knows debian has black magic involved sometimes
[14:47] <alan_g> kgunn: it is about time. Anything outstanding you'd like to land?
[14:47] <kgunn> let me skim again
[14:47]  * alan_g leaves debian foo to others. Is there any reason to do either?
[14:51] <kgunn> alan_g: ok...there's 2 branches up for merging...may as well wait for those to get in
[14:51] <alan_g> kgunn: one just failed
[14:52] <kgunn> besides that..there's "ping" and then the "build opts for test" (that requires coord)
[14:52] <kgunn> dang it
[14:53] <kgunn> alan_g: sorry...which one are you referring to that just failed ?
[14:53] <alan_g> kgunn: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510
[14:55]  * alan_g feels guilty as he just wrote the test that failed: DemoInProcessServer.client_can_connect
[14:56] <alan_g> kgunn: Looks like we just landed a flaky test.
[14:57] <kgunn> alan_g: hopefully that'll make it simple to fix :)
[14:57] <kgunn> looking for the bright side
[14:59] <alan_g> kgunn: There's some useful looking test output. But so far I can't reproduce (but only run it n0000 times)
[15:00] <alan_g> \o/ running under valgrind I can reproduce after on iteration 20521
[15:00] <alan_g> s/after //
[15:01] <kgunn> goodness
[15:01] <kgunn> how much luck must it take to have hit that
[15:06] <alan_g> kgunn: I think it is an unforseen interaction between alf_'s work to sync across processes and my test that runs in a single process.
[15:12] <anpok> hm I have a crash in mesa
[15:13] <anpok> in platform_drm.c
[15:15] <alan_g> kgunn: want a quick and dirty fix to unblock things? (With a cleanup fix a few hours later)
[15:15] <kgunn> alan_g: nah...go for the cleanup fix if its truly just few hours...
[15:16] <kgunn> alan_g: i'll work my afternoon to queue up the merge to lp:mir once it lands
[15:18] <alan_g> kgunn: It truly is - it just means we need a new class in the testing configuration hierarchy. (I've a working POC that extends the hierarchy to disable alf_'s sync stuff)
[15:19] <kgunn> alan_g|tea: sounds good...i'd rather just do it right and avoid sinking your time into band-aids
[15:50] <anpok> need a break..
[15:51] <anpok> is the mesa inside the trusty archives (10.0.0-1ubuntu4) working for you?
[15:53] <alan_g> I assume that's what I'm running.
[16:53] <alan_g> kgunn: as promised (less than 2 hours later) - https://code.launchpad.net/~alan-griffiths/mir/fix-1262754/+merge/199688
[16:56] <alan_g> There must be a better way to represent moved code than large swatches of red and green
[16:59] <kgunn> alan_g: thank you
[17:00] <kgunn> ...i quite like the red/green representation
[17:01] <alan_g> But moving code doesn't entail the same risks as deleting old and writing new
[17:01] <kgunn> mmm true
[17:03]  * alan_g wishes once more for a VCS that understands refactoring
[17:56] <anpok> alan_g: there is a vcs project that does that ..it parses the source code and is able to detect certain patterns, like renaming a method, moving it up or down in the inheritance hierachy
[17:56] <anpok> or detects similar fixes on different levels of the hierachy and presents logical merge conflicts..
[17:56] <anpok> cannot remember its name
[17:56] <alan_g> anpok: once upon a time I was told bzr would do that.
[17:57] <anpok> stories with a happy ending that way
[18:00] <alan_g> if I rename something and someone else adds a use of it the VCS should sort be able to it out.
[20:48] <anpok> ok it was my error my self built mesa version was interfering ..
[20:49] <anpok> now with current mesa from trusty i get an unsuported platform warning in the nested case
[21:01] <fishscene> How are Mir milestones reached? Are they reached by tasks accomplished? or is it by date/time? Relevant link: https://launchpad.net/mir 
[22:35] <kgunn> fishscene: you might have noticed we're working on a dev branch which gets promoted to our "sacred trunk" which feeds the archive/touch images...
[22:35] <kgunn> we're promoting approximately fortnightly
[22:35] <kgunn> although...every now and then
[22:36] <kgunn> like...the last 2 weeks :)
[22:36] <kgunn> we've been wrestling with our ci infrastructure (our automated testing)
[22:36] <kgunn> which we need to be fully passing to promote
[22:37] <kgunn> at any rate that's the rough correlation...so schedule based more than task based
[22:37] <kgunn> driven mostly by the fact we don't want the dev to get too diverged from whats in archive
[22:37] <kgunn> hth
[22:52] <fishscene> kgunn: Gotchya. Thanks for taking the time to fill me in. :)