[04:17] veebers: still around? anything I can do tomorrow to help with the remaining autopilot tasks? [04:30] elopio: hey yeah I'm still around for about an hour or so [04:30] elopio: I'm just pushing up some updated code and finishing a review and would like your thoughts on somethings [04:42] elopio: if you have a moment can you read the comments and reviews from this MP: https://code.launchpad.net/~canonical-platform-qa/autopilot/cpo-base-classes-fix/+merge/257623 [04:42] specifically I'm interested in your thoughts on what I wrote in the comment box [04:46] veebers: on it. [04:47] veebers: I agree on the warning. [04:48] we are still using multiple inheritance in the sanity suite. [04:48] when we remove that, we can raise the exception. [04:48] oh well, but the multiple inheritance in the sanity won't affect this because it's not on the base class. Anyway, I agree with you. [04:52] elopio: coolio :-) [04:55] elopio: hmm, I thought that we had discussed updating the narrative/docs for the cpo/selection thing as a separate card, or am I miss-remembering things? [04:59] isn't there a separate card? The one called "Add documentation for the narrative docs" ? [05:01] elopio: I see one in play now called "Add documentation for the narrative docs (i.e. FAQ and section on creating CPOs)" (on the board) [05:02] veebers: yes, so I don't get what you mean. [05:06] elopio: oh, I meant I thought that we weren't doing that card this sprint as we needed the other cards to land/be finished first' [05:07] veebers: ahh. Then I'm not sure. [05:07] veebers: but now that the branch is almost ready, we can prepare the doc updates, right:? [05:12] elopio: yeah I guess thats a good point, I was thinking with my EOD-ing soon hat on :-) I will be back online after dinner though [05:15] veebers: should I throw a gatekeeper now, or wait for the branch to be merged? [05:17] elopio: for a gatekeeper run we need it to be built into a ppa, are you suggesting setting up a silo for it? [05:25] veebers: no, not really. I thought we could run a gatekeeper from a branch. [05:25] if it requires a silo, I think we better wait for the branches to land. Things look good, the unit tests look good. I doubt we will cause a regression, and if so, it should be solved by the fix_base_class branches landing. [05:26] elopio: as far as I'm aware the gatekeeper (the same as the smoke dash job) runs from a ppa [05:26] veebers: yes, I remember now the ppa parameter. It was just a stupid question :) [05:27] elopio: Not stupid, I good idea. I know vila has mentioned that he has ideas on improving how we test and release autopilot incl. ppas etc. [05:27] ah, right, what he said now makes sense. === ara is now known as Guest6469 === chihchun is now known as chihchun_afk [08:23] jibel: given the history of http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-firefox/ how can we edit the history files on snakefruit to stop considering this a regression? [08:25] jibel: do we need to edit all PASSes in proposed-migration/autopkgtest/data/adt/trusty-proposed/amd64/archive/*/*/*/trusty_amd64_firefox_*.result ? [08:26] pitti, if you remove this line it should be considered as 'always failed' firefox 24.0+build1-0ubuntu1 PASS fonts-liberation 1.07.3-3 [08:27] in the history file [08:27] jibel: ah, good; thanks! [08:28] jibel: I'm going through the trusty failures, and fixed a few bugs in autopkgtest; others like firefox need some fumbling [08:29] pitti, firefox used to pass but it looks like no one maintains the testsuite in ubuntu any more [08:30] this is sad because it found real regressions [08:30] yeah, same in vivid [15:14] vila: btw, now your autopilot ppa makes a lot of sense to me for running the gatekeeper before having a silo. [15:19] elopio: sorry, I should have been clearer about that [15:20] elopio, fgimenez: But w really need something faster, >4h for one iteration kills velocity (understatement) [15:20] vila: parallelization? [15:21] elopio, fgimenez: we'll need to at least split the tests to run on 2 phones [15:21] elopio: yup, coarse grained one at the highest level to start with [15:22] vila: and we also want the things they are doing on ci.ubuntu.com for the run to continue even if one suite killed a phone. [15:22] but how do we put this in CI's backlog? so many things in there. [15:22] elopio: well, in that case we may as well run each suite on its own but... [15:23] elopio: that's why I'm saying we focus on getting access to run autopkgtest on phones/qemu [15:24] elopio: from there we can add the missing dep8 tests to wrap autopilot in all packages and aggregate the subunit streams ourselves [15:24] vila: that sounds good. [15:24] jfunk_: ^ [15:25] if ci gives us this command that provissions a phone every time we want it, we can take care of all the other details. [15:25] then maybe we can go faster. [15:40] elopio: exactly, including prototyping gates [16:00] elopio, thanks for your comment on mp. Is this the change that you meant? http://pastebin.ubuntu.com/10953708/ [16:01] rhuddie: yes, I think so. Does it make sense to you? [16:01] elopio, yes, that makes sense. I just wanted to check I understood correctly before pushing [16:02] ok, thanks. === oSoMoN__ is now known as oSoMoN [17:05] om26er: I wouldn't extract os.path.exists(directory) into a method. [17:06] is clear enough, and only one statement. [17:07] elopio, its subjective, I prefer to have methods as explanatory as possible and would prefer to follow DRY [17:08] om26er: you are only using it once, so there will be no duplication. [17:08] elopio, in two places in the same method. [17:08] om26er: ah, that's right. [17:09] but you are not adding clarity and you are not saving lines of code. [17:09] you are adding three lines instead. [17:09] elopio, that's why I ask if we could use a better name for the method [17:09] om26er: os.path.exists is a name good enough. [17:10] the name of your method is alright. It just should end with an s. directory_existS. [17:11] but you shouldn't write a method if there's no value on it. You are just making an alias for os.path.exists. [17:11] elopio, hmm, ok. I have seen people in well written project not calling the public api twice in their codes, they rather encapsulate the call in a method [17:11] elopio, hmm, sure I can change that back. [17:13] om26er: we don't need to shield ourselfs from the python standard libraries. We don't need to replace them with fakes for testing either. [17:13] encapsulating external projects is good, sometimes. Here I see no reason to do it. [17:18] elopio, ok, I pushed the change. There are older flake8 warnings in the file, want me to do that in this MR or is that better for separate MR ? [17:19] om26er: separate MP, according to a discussion I lost against thomi and veebers. [17:19] om26er: but: https://bugs.launchpad.net/ubuntu-keyboard/+bug/1444170 [17:19] Ubuntu bug 1444170 in unity8 (Ubuntu) "python code does not pass the flake8 static checks" [Medium,In progress] [17:19] if you use the flake8 as a prerequisite of your branch it would be easier, I think. === davmor2_ is now known as davmor2 === rsalveti_ is now known as rsalveti [19:54] veebers: so, about the presentation for ODS, the idea is to quickly show how easy it is to write a high level integration test with the helpers in the toolkit and unity8. [19:54] balloons wanted to show the helpers docs published, so the first step was to get the unity8 namespace right. [19:54] https://code.launchpad.net/~canonical-platform-qa/unity8/fix1306340-deprecate_emulators/+merge/257812 [19:54] next step is to generate sphinx out of that branch. [20:07] * veebers looks at branch [20:11] elopio_: there is more changes in that MP than just deprecating the emulators ;-) [20:11] oh wait, that probably comes from the branches you mention in the message === \b is now known as benonsoftware