elopio | veebers: still around? anything I can do tomorrow to help with the remaining autopilot tasks? | 04:17 |
---|---|---|
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:30 |
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:42 |
elopio | veebers: on it. | 04:46 |
elopio | veebers: I agree on the warning. | 04:47 |
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:48 |
veebers | elopio: coolio :-) | 04:52 |
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:55 |
elopio | isn't there a separate card? The one called "Add documentation for the narrative docs" ? | 04:59 |
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:01 |
elopio | veebers: yes, so I don't get what you mean. | 05:02 |
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:06 |
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:07 |
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:12 |
elopio | veebers: should I throw a gatekeeper now, or wait for the branch to be merged? | 05:15 |
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:17 |
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:25 |
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:26 |
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. | 05:27 |
=== ara is now known as Guest6469 | ||
=== chihchun is now known as chihchun_afk | ||
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:23 |
pitti | jibel: do we need to edit all PASSes in proposed-migration/autopkgtest/data/adt/trusty-proposed/amd64/archive/*/*/*/trusty_amd64_firefox_*.result ? | 08:25 |
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:26 |
jibel | in the history file | 08:27 |
pitti | jibel: ah, good; thanks! | 08:27 |
pitti | jibel: I'm going through the trusty failures, and fixed a few bugs in autopkgtest; others like firefox need some fumbling | 08:28 |
jibel | pitti, firefox used to pass but it looks like no one maintains the testsuite in ubuntu any more | 08:29 |
jibel | this is sad because it found real regressions | 08:30 |
pitti | yeah, same in vivid | 08:30 |
elopio | vila: btw, now your autopilot ppa makes a lot of sense to me for running the gatekeeper before having a silo. | 15:14 |
vila | elopio: sorry, I should have been clearer about that | 15:19 |
vila | elopio, fgimenez: But w really need something faster, >4h for one iteration kills velocity (understatement) | 15:20 |
elopio | vila: parallelization? | 15:20 |
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:21 |
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:22 |
vila | elopio: that's why I'm saying we focus on getting access to run autopkgtest on phones/qemu | 15:23 |
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:24 |
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:25 |
vila | elopio: exactly, including prototyping gates | 15:40 |
rhuddie | elopio, thanks for your comment on mp. Is this the change that you meant? http://pastebin.ubuntu.com/10953708/ | 16:00 |
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:01 |
elopio | ok, thanks. | 16:02 |
=== oSoMoN__ is now known as oSoMoN | ||
elopio | om26er: I wouldn't extract os.path.exists(directory) into a method. | 17:05 |
elopio | is clear enough, and only one statement. | 17:06 |
om26er | elopio, its subjective, I prefer to have methods as explanatory as possible and would prefer to follow DRY | 17:07 |
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:08 |
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:09 |
elopio | the name of your method is alright. It just should end with an s. directory_existS. | 17:10 |
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:11 |
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:13 |
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:18 |
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 |
ubot5 | Ubuntu bug 1444170 in unity8 (Ubuntu) "python code does not pass the flake8 static checks" [Medium,In progress] | 17:19 |
elopio | if you use the flake8 as a prerequisite of your branch it would be easier, I think. | 17:19 |
=== davmor2_ is now known as davmor2 | ||
=== rsalveti_ is now known as rsalveti | ||
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. | 19:54 |
* veebers looks at branch | 20:07 | |
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 | 20:11 |
=== \b is now known as benonsoftware |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!