[04:17] <elopio> veebers: still around? anything I can do tomorrow to help with the remaining autopilot tasks?
[04:30] <veebers> elopio: hey yeah I'm still around for about an hour or so
[04:30] <veebers> elopio: I'm just pushing up some updated code and finishing a review and would like your thoughts on somethings
[04:42] <veebers> 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] <veebers> specifically I'm interested in your thoughts on what I wrote in the comment box
[04:46] <elopio> veebers: on it.
[04:47] <elopio> veebers: I agree on the warning.
[04:48] <elopio> we are still using multiple inheritance in the sanity suite.
[04:48] <elopio> when we remove that, we can raise the exception.
[04:48] <elopio> 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] <veebers> elopio: coolio :-)
[04:55] <veebers> 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] <elopio> isn't there a separate card? The one called "Add documentation for the narrative docs" ?
[05:01] <veebers> 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] <elopio> veebers: yes, so I don't get what you mean.
[05:06] <veebers> 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] <elopio> veebers: ahh. Then I'm not sure.
[05:07] <elopio> veebers: but now that the branch is almost ready, we can prepare the doc updates, right:?
[05:12] <veebers> 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] <elopio> veebers: should I throw a gatekeeper now, or wait for the branch to be merged?
[05:17] <veebers> 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] <elopio> veebers: no, not really. I thought we could run a gatekeeper from a branch.
[05:25] <elopio> 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] <veebers> elopio: as far as I'm aware the gatekeeper (the same as the smoke dash job) runs from a ppa
[05:26] <elopio> veebers: yes, I remember now the ppa parameter. It was just a stupid question :)
[05:27] <veebers> 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] <elopio> ah, right, what he said now makes sense.
[08:23] <pitti> 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] <pitti> jibel: do we need to edit all PASSes in proposed-migration/autopkgtest/data/adt/trusty-proposed/amd64/archive/*/*/*/trusty_amd64_firefox_*.result ?
[08:26] <jibel> 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] <jibel> in the history file
[08:27] <pitti> jibel: ah, good; thanks!
[08:28] <pitti> jibel: I'm going through the trusty failures, and fixed a few bugs in autopkgtest; others like firefox need some fumbling
[08:29] <jibel> pitti, firefox used to pass but it looks like no one maintains the testsuite in ubuntu any more
[08:30] <jibel> this is sad because it found real regressions
[08:30] <pitti> yeah, same in vivid
[15:14] <elopio> vila: btw, now your autopilot ppa makes a lot of sense to me for running the gatekeeper before having a silo.
[15:19] <vila> elopio: sorry, I should have been clearer about that
[15:20] <vila> elopio, fgimenez: But w really need something faster, >4h for one iteration kills velocity (understatement)
[15:20] <elopio> vila: parallelization?
[15:21] <vila> elopio, fgimenez: we'll need to at least split the tests to run on 2 phones
[15:21] <vila> elopio: yup, coarse grained one at the highest level to start with
[15:22] <elopio> 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] <elopio> but how do we put this in CI's backlog? so many things in there.
[15:22] <vila> elopio: well, in that case we may as well run each suite on its own but...
[15:23] <vila> elopio: that's why I'm saying we focus on getting access to run autopkgtest on phones/qemu
[15:24] <vila> elopio: from there we can add the missing dep8 tests to wrap autopilot in all packages and aggregate the subunit streams ourselves
[15:24] <elopio> vila: that sounds good.
[15:24] <elopio> jfunk_: ^
[15:25] <elopio> 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] <elopio> then maybe we can go faster.
[15:40] <vila> elopio: exactly, including prototyping gates
[16:00] <rhuddie> elopio, thanks for your comment on mp. Is this the change that you meant? http://pastebin.ubuntu.com/10953708/
[16:01] <elopio> rhuddie: yes, I think so. Does it make sense to you?
[16:01] <rhuddie> elopio, yes, that makes sense. I just wanted to check I understood correctly before pushing
[16:02] <elopio> ok, thanks.
[17:05] <elopio> om26er: I wouldn't extract os.path.exists(directory) into a method.
[17:06] <elopio> is clear enough, and only one statement.
[17:07] <om26er> elopio, its subjective, I prefer to have methods as explanatory as possible and would prefer to follow DRY
[17:08] <elopio> om26er: you are only using it once, so there will be no duplication.
[17:08] <om26er> elopio, in two places in the same method.
[17:08] <elopio> om26er: ah, that's right.
[17:09] <elopio> but you are not adding clarity and you are not saving lines of code.
[17:09] <elopio> you are adding three lines instead.
[17:09] <om26er> elopio, that's why I ask if we could use a better name for the method
[17:09] <elopio> om26er: os.path.exists is a name good enough.
[17:10] <elopio> the name of your method is alright. It just should end with an s. directory_existS.
[17:11] <elopio> 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] <om26er> 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] <om26er> elopio, hmm, sure I can change that back.
[17:13] <elopio> 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] <elopio> encapsulating external projects is good, sometimes. Here I see no reason to do it.
[17:18] <om26er> 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] <elopio> om26er: separate MP, according to a discussion I lost against thomi and veebers.
[17:19] <elopio> om26er: but: https://bugs.launchpad.net/ubuntu-keyboard/+bug/1444170
[17:19] <elopio> if you use the flake8 as a prerequisite of your branch it would be easier, I think.
[19:54] <elopio_> 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] <elopio_> balloons wanted to show the helpers docs published, so the first step was to get the unity8 namespace right.
[19:54] <elopio_> https://code.launchpad.net/~canonical-platform-qa/unity8/fix1306340-deprecate_emulators/+merge/257812
[19:54] <elopio_> next step is to generate sphinx out of that branch.
[20:07]  * veebers looks at branch
[20:11] <veebers> elopio_: there is more changes in that MP than just deprecating the emulators ;-)
[20:11] <veebers> oh wait, that probably comes from the branches you mention in the message