| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| pitti | jibel: could we enable your DKMS adt-britney bit now? | 10:16 |
|---|---|---|
| jibel | pitti, there is a W? | 10:17 |
| pitti | jibel: 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 |
| pitti | jibel: no, for T/U/V | 10:17 |
| jibel | pitti, we can create a request file and submit it manually | 10:17 |
| pitti | jibel: but we are past the V release, so time for experimentation :) | 10:17 |
| jibel | from sankefruit | 10:17 |
| jibel | snakefruit* | 10:17 |
| elopio | rhuddie: http://people.canonical.com/~nskaggs/autopilot/tutorial/advanced_autopilot.html#writing-custom-proxy-classes | 14:22 |
| elopio | I think what we need is to expand on point #3 | 14:22 |
| rhuddie | elopio, thank you | 14:23 |
| === rbasak_ is now known as rbasak | ||
| balloons | elopio, did you get anywhere with documenting the unity AP helpers? | 14:57 |
| elopio | balloons: not yet. I did a couple of cleanups first, already approved. | 15:00 |
| === chihchun is now known as chihchun_afk | ||
| elopio | ping pitti: I'm wondering about running tests during click or snap builds, like dh_auto_test | 16:03 |
| elopio | have you considered that? | 16:04 |
| pitti | elopio: 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 snap | 16:05 |
| pitti | elopio: but of course they can run "make check" or similar, and are encouraged to do so | 16:05 |
| elopio | pitti: right. And should we include that make check on the x-test section of the manifest too? | 16:07 |
| alesage | pitti at some point we as the QA dept. would want to make sure those tests are run, right? or am I misunderstanding | 16:08 |
| alesage | maybe I'm dropping in on an unrelated conversation there, apologies if so pitti | 16:11 |
| pitti | elopio: 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 expensive | 16:12 |
| pitti | elopio: and we can't yet do that on clicks and snaps as long as we don't formalize how to actually build them | 16:12 |
| pitti | the idea is that you run the fine-grained unit tests during upstream development and package build | 16:13 |
| pitti | and then use some more coarse-grained "smoke tests" for "installed package" testing, which gets run whenever your dependencies change | 16:13 |
| pitti | to make sure that they don't break you | 16:13 |
| pitti | (and most of our autopkgtests are in shell or python, so they don't need a full package build) | 16:14 |
| pitti | alesage: yes, absolutely | 16:14 |
| pitti | alesage: snap packages are still in its infancy, I don't think tests for them have been discussed at all yet | 16:14 |
| alesage | pitti 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 away | 16:15 |
| pitti | alesage: yeah, these need to become part of the click/snap build then | 16:16 |
| alesage | pitti, 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 |
| pitti | running "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 tests | 16:19 |
| elopio | pitti: 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 |
| alesage | interesting :) pitti, there'll be a divide there between us as the "shippers of packages" and "those who pack the packages" | 16:21 |
| elopio | seems like a good discussion. For packages that want to run their tests during build time, how do we allow it? | 16:21 |
| pitti | elopio: 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 frameworks | 16:23 |
| pitti | elopio: we can't allow or forbid it | 16:23 |
| pitti | elopio: 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 control | 16:24 |
| pitti | we can and should give recommendations and tools etc., of coruse | 16:24 |
| === chihchun_afk is now known as chihchun | ||
| elopio | alesage: nothing conclusive, just ideas floating around. | 17:16 |
| elopio | pitti is right of course. It's up to the developers of the snapps and clicks to make sure they are high quality. | 17:17 |
| alesage | elopio true but we as a dept. have a stake in that of course | 17:17 |
| elopio | we need to agree on the format to define tests as installed, that's the first point I think. | 17:17 |
| alesage | elopio, when you say "define tests as installed", you mean to differentiate what should be run pre- and post-install? | 17:18 |
| pitti | for 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 to | 17:19 |
| elopio | alesage: 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 |
| elopio | on pre-install, we can probably only make recommendations. | 17:19 |
| elopio | what I would suggest is to start working with the people currently writing snaps, and see how they run their unit tests. | 17:20 |
| alesage | pitti, would running make-check be a way to "opt-in" for build-time testing on our infrastructure, e.g.? | 17:20 |
| alesage | weird that what I think of as "CI" is kind-of going away under this regime | 17:21 |
| elopio | we 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 |
| elopio | this is a whole new world. Maybe reviews are even more useful than tests for some situations. | 17:23 |
| alesage | maybe think of it as "providing services" to devs who wish to use the build-time testing? | 17:25 |
| alesage | elopio? ^^ | 17:25 |
| elopio | maybe. | 17:26 |
| elopio | alesage: but if we tell them: here's this tool to run your tests. Use it if you want. | 17:27 |
| elopio | that's the same as saying, run your make check before pushing to trunk, if you want. | 17:27 |
| elopio | so maybe we don't have to do anything on the tools, just seed some best practices on the sample snapps. | 17:28 |
| alesage | elopio, right, at least traditionally we'd be running make check too, to gate on commits to trunk :) | 17:28 |
| elopio | alesage: right. Maybe we need a way for snapp developers to tell launchpad what to run on MPs. | 17:29 |
| elopio | github already has that with travis CI. | 17:29 |
| alesage | elopio, right, so the question is whether this continues to be the deb infrastructure or something else, e.g. autopkgtest | 17:30 |
| elopio | many questions. | 17:32 |
| pitti | alesage: we don't build snaps/clicks on our infrastructure in general | 17:32 |
| alesage | elopio possibly CI has answers? | 17:32 |
| pitti | alesage: for those that we build ourselves, we can of course mandate folks to run "make check" or the moral equivalent in their buildl scripts | 17:32 |
| elopio | alesage: I doubt it. I think the answers will come from the snappy team. | 17:33 |
| pitti | but yeah, for snaps themselves the CI is pretty much out of our hands | 17:34 |
| pitti | what 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 regressions | 17:35 |
| * pitti waves good night, time for basketball | 17:35 | |
| alesage | pitti enjoy :) | 17:35 |
| elopio | bye pitti. | 17:37 |
| elopio | thank you. | 17:37 |
| elopio | alesage: 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 |
| alesage | elopio o interesting, good idea, need to jump on that right away | 17:39 |
| elopio | balloons: 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 |
| balloons | elopio, ohh fun. | 18:25 |
| elopio | so I will prepare the branch, but during the session I'll talk about things not yet released. | 18:25 |
| balloons | elopio, sure I guess that works. And in general we want to cover what they are and how you can use / make your own as well | 18:25 |
| balloons | so we'll still have content to talk about | 18:25 |
| elfy | evening balloons | 18:27 |
| balloons | evening elfy | 18:29 |
| elopio | balloons: want to give it an early review? | 19:25 |
| elopio | http://bazaar.launchpad.net/~canonical-platform-qa/unity8/fix1306340-deprecate_emulators/revision/1531 | 19:25 |
| balloons | elopio, sure | 19:30 |
| balloons | elopio, preference question; get_pinPadLoader.. do you like this better than get_pinpadloader, or get_pinpad_loader, etc? | 19:33 |
| elopio | balloons: get_pinpad_loader | 19:33 |
| balloons | good, we agree :-) | 19:33 |
| elopio | probably, _get_pinpad_loader, as something like that shouldn't be public. | 19:34 |
| balloons | right right.. | 19:34 |
| balloons | going to change the name of tests/autopilot/unity8/shell/emulators.py ? | 19:35 |
| elopio | balloons: that will remain there in case somebody was importing it from a different project. | 19:43 |
| balloons | Letozaf_, 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 strange | 19:49 |
| Letozaf_ | balloons, I would expect the property to be 6 when en_US locale and 0 when it_IT locale | 19:50 |
| Letozaf_ | balloons, but it is 1 with it_IT and 0 with en_US | 19:51 |
| Letozaf_ | balloons, I can fix the code to work with 1 and 0 but not sure that is ok for other locales | 19:51 |
| Letozaf_ | Letozaf_, I wrote a note in the mp | 19:51 |
| balloons | Letozaf_, awesome. I saw your note about weird values | 19: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 it | 19:57 |
| elopio | alesage: do you have an example for a cmake check task that includes static analysis? | 20:06 |
| alesage | elopio no I don't | 20:06 |
| elopio | I would like to add flake8 to the camera. I would prefer to copy it from somewhere else. | 20:06 |
| alesage | elopio 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 |
| elopio | alesage: the camera is a click app. | 20:07 |
| alesage | elopio, o hey man | 20:07 |
| alesage | elopio, I see--straining to remember who might've done this already | 20:08 |
| alesage | elopio, seeing that they have a run_tests script, maybe it belongs there? | 20:11 |
| alesage | elopio, in lp:indicator-datetime you could follow the pattern of GCov.cmake, e.g. | 20:18 |
| alesage | elopio, similar case in that it's calling those executables after build, etc. | 20:19 |
| elopio | alesage: I've just found MPs are building the debs, maybe it's not yet a click, or is both? | 20:19 |
| elopio | anyway, I pushed it for now in the debian/rules. | 20:19 |
| elopio | will look at the indicator. Thanks. | 20:19 |
| alesage | elopio interesting ok | 20:19 |
| alesage | elopio also lp:cmake-extras would be a destination for a general-purpose flake8 macro | 20:21 |
| alesage | elopio fwiw not seeing anything relevant in the standard cmake modules # dpkg -L cmake-data | 20:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!