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