=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
pittijibel: could we enable your DKMS adt-britney bit now?10:16
jibelpitti, there is a W?10:17
pittijibel: is there a way to pretend that britney asked for testing a particular package (manually creating a request file?) so that we can see how this looks in jenkins?10:17
pittijibel: no, for T/U/V10:17
jibelpitti, we can create a request file and submit it manually10:17
pittijibel: but we are past the V release, so time for experimentation :)10:17
jibelfrom sankefruit10:17
elopiorhuddie: http://people.canonical.com/~nskaggs/autopilot/tutorial/advanced_autopilot.html#writing-custom-proxy-classes14:22
elopioI think what we need is to expand on point #314:22
rhuddieelopio, thank you14:23
=== rbasak_ is now known as rbasak
balloonselopio, did you get anywhere with documenting the unity AP helpers?14:57
elopioballoons: not yet. I did a couple of cleanups first, already approved.15:00
=== chihchun is now known as chihchun_afk
elopioping pitti: I'm wondering about running tests during click or snap builds, like dh_auto_test16:03
elopiohave you considered that?16:04
pittielopio: that's up to the click's/snap's creator really; ATM we don't even know how to (formally) build a click correctly, and even less so a snap16:05
pittielopio: but of course they can run "make check" or similar, and are encouraged to do so16:05
elopiopitti: right. And should we include that make check on the x-test section of the manifest too?16:07
alesagepitti at some point we as the QA dept. would want to make sure those tests are run, right?  or am I misunderstanding16:08
alesagemaybe I'm dropping in on an unrelated conversation there, apologies if so pitti16:11
pittielopio: that's more complicated; for debs you can choose to build the package again during autopkgtest and run teh compiled tests, but in general we don't encourage that as it's expensive16:12
pittielopio: and we can't yet do that on clicks and snaps as long as we don't formalize how to actually build them16:12
pittithe idea is that you run the fine-grained unit tests during upstream development and package build16:13
pittiand then use some more coarse-grained "smoke tests" for "installed package" testing, which gets run whenever your dependencies change16:13
pittito make sure that they don't break you16:13
pitti(and most of our autopkgtests are in shell or python, so they don't need a full package build)16:14
pittialesage: yes, absolutely16:14
pittialesage: snap packages are still in its infancy, I don't think tests for them have been discussed at all yet16:14
alesagepitti ok so I don't have as much catching up to do as I thought :) , just concerned with unit and QML tests specifically, i.e. if dh_auto_test goes away16:15
pittialesage: yeah, these need to become part of the click/snap build then16:16
alesagepitti, so ultimately we want to acclimate devs to autopkgtest (as the "build"-testing env), maybe develop a way to ensure those are run on our side?16:17
pittirunning "installed package" tests is in some way easier, as we don't need to rebuild (or know how to build) a package in order to run its tests16:19
elopiopitti: ok. I was thinking of getting the store running the static and unit tests when a package is being updated, but I had forgotten about packages that can come without sourcecode.16:20
alesageinteresting :) pitti, there'll be a divide there between us as the "shippers of packages" and "those who pack the packages"16:21
elopioseems like a good discussion. For packages that want to run their tests during build time, how do we allow it?16:21
pittielopio: yeah, that too; what the snap builder does is their thing, but I guess if we have tests for installed snaps we want to run them to ensure we don't break stuff when we e. g. update frameworks16:23
pittielopio: we can't allow or forbid it16:23
pittielopio: how the creator of a snap pieces together a snap and what he does or doesn't do to build it is outside of our control16:24
pittiwe can and should give recommendations and tools etc., of coruse16:24
=== chihchun_afk is now known as chihchun
elopioalesage: nothing conclusive, just ideas floating around.17:16
elopiopitti is right of course. It's up to the developers of the snapps and clicks to make sure they are high quality.17:17
alesageelopio true but we as a dept. have a stake in that of course17:17
elopiowe need to agree on the format to define tests as installed, that's the first point I think.17:17
alesageelopio, when you say "define tests as installed", you mean to differentiate what should be run pre- and post-install?17:18
pittifor clicks we only have the equivalent of autopkgtests defined (and we run those); we don't define package build tests as we don't really have to17:19
elopioalesage: I think we can only define what will be post-install. We need that to be a known API so it's run automatically after the package is installed and the canary updates can work.17:19
elopioon pre-install, we can probably only make recommendations.17:19
elopiowhat I would suggest is to start working with the people currently writing snaps, and see how they run their unit tests.17:20
alesagepitti, would running make-check be a way to "opt-in" for build-time testing on our infrastructure, e.g.?17:20
alesageweird that what I think of as "CI" is kind-of going away under this regime17:21
elopiowe could make "click build" (or snap build) a little smarter to find a make check if there's one, or to be able to overwrite the build rules as debs do. But the level of enforcing of the process I was initially thinking about is definitely not possible. And even that might be going too far.17:22
elopiothis is a whole new world. Maybe reviews are even more useful than tests for some situations.17:23
alesagemaybe think of it as "providing services" to devs who wish to use the build-time testing?17:25
alesageelopio? ^^17:25
elopioalesage: but if we tell them: here's this tool to run your tests. Use it if you want.17:27
elopiothat's the same as saying, run your make check before pushing to trunk, if you want.17:27
elopioso maybe we don't have to do anything on the tools, just seed some best practices on the sample snapps.17:28
alesageelopio, right, at least traditionally we'd be running make check too, to gate on commits to trunk :)17:28
elopioalesage: right. Maybe we need a way for snapp developers to tell launchpad what to run on MPs.17:29
elopiogithub already has that with travis CI.17:29
alesageelopio, right, so the question is whether this continues to be the deb infrastructure or something else, e.g. autopkgtest17:30
elopiomany questions.17:32
pittialesage: we don't build snaps/clicks on our infrastructure in general17:32
alesageelopio possibly CI has answers?17:32
pittialesage: for those that we build ourselves, we can of course mandate folks to run "make check" or the moral equivalent in their buildl scripts17:32
elopioalesage: I doubt it. I think the answers will come from the snappy team.17:33
pittibut yeah, for snaps themselves the CI is pretty much out of our hands17:34
pittiwhat we can do is to run the installed tests (i. e. autopkgtests) for existing snaps (if they provide some) when we change frameworks, to ensure that there are no regressions17:35
* pitti waves good night, time for basketball17:35
alesagepitti enjoy :)17:35
elopiobye pitti.17:37
elopiothank you.17:37
elopioalesage: I think that the snappy team is running their own tests on MPs outside of our CI infrastructure. So we should look into it, and ask CI to support this new usecases.17:38
alesageelopio o interesting, good idea, need to jump on that right away17:39
elopioballoons: I have a problem. Three of our branches will conflict with the cleanup of the unity8 namespace, and we won't have a unity8 release soon.18:24
balloonselopio, ohh fun.18:25
elopioso I will prepare the branch, but during the session I'll talk about things not yet released.18:25
balloonselopio, sure I guess that works. And in general we want to cover what they are and how you can use / make your own as well18:25
balloonsso we'll still have content to talk about18:25
elfyevening balloons18:27
balloonsevening elfy18:29
elopioballoons: want to give it an early review?19:25
balloonselopio, sure19:30
balloonselopio, preference question; get_pinPadLoader.. do you like this better than get_pinpadloader, or get_pinpad_loader, etc?19:33
elopioballoons: get_pinpad_loader19:33
balloonsgood, we agree :-)19:33
elopioprobably, _get_pinpad_loader, as something like that shouldn't be public.19:34
balloonsright right..19:34
balloonsgoing to change the name of tests/autopilot/unity8/shell/emulators.py ?19:35
elopioballoons: that will remain there in case somebody was importing it from a different project.19:43
balloonsLetozaf_, everything go ok with calendar?19:48
Letozaf_balloons, hello :)19:49
Letozaf_balloons, yes the change made by Kunal is great, but the value the property he added is quite strange19:49
Letozaf_balloons, I would expect the property to be 6 when en_US locale and 0 when it_IT locale19:50
Letozaf_balloons, but it is 1 with it_IT and 0 with en_US19:51
Letozaf_balloons, I can fix the code to work with 1 and 0 but not sure that is ok for other locales19:51
Letozaf_Letozaf_, I wrote a note in the mp19:51
balloonsLetozaf_, awesome. I saw your note about weird values19:55
Letozaf_balloons, :)19:55
Letozaf_balloons, I put the fix here: https://code.launchpad.net/~carla-sella/ubuntu-calendar-app/fix-dayview-default-view/+merge/257814 but I am waiting for Kunal's answer so to fix it with 6 and 0 as I would do it19:57
elopioalesage: do you have an example for a cmake check task that includes static analysis?20:06
alesageelopio no I don't20:06
elopioI would like to add flake8 to the camera. I would prefer to copy it from somewhere else.20:06
alesageelopio O I see, I'd probably add it to the debian rules--don't we do that somewhere in our qa repos already?20:07
elopioalesage: the camera is a click app.20:07
alesageelopio, o hey man20:07
alesageelopio, I see--straining to remember who might've done this already20:08
alesageelopio, seeing that they have a run_tests script, maybe it belongs there?20:11
alesageelopio, in lp:indicator-datetime you could follow the pattern of GCov.cmake, e.g.20:18
alesageelopio, similar case in that it's calling those executables after build, etc.20:19
elopioalesage: I've just found MPs are building the debs, maybe it's not yet a click, or is both?20:19
elopioanyway, I pushed it for now in the debian/rules.20:19
elopiowill look at the indicator. Thanks.20:19
alesageelopio interesting ok20:19
alesageelopio also lp:cmake-extras would be a destination for a general-purpose flake8 macro20:21
alesageelopio fwiw not seeing anything relevant in the standard cmake modules # dpkg -L cmake-data20:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!