| fagan | ogasawara: did you announce the kernel bug day on planet ubuntu? | 02:48 |
|---|---|---|
| fagan | ill do it if you want | 02:48 |
| fagan | Ok done | 02:58 |
| ogasawara | fagan: thanks | 06:09 |
| fagan | ogasawara: no bother | 06:11 |
| ara | good morning all :-) | 06:28 |
| fagan | morning ara | 06:28 |
| ara | hey fagan :) | 06:29 |
| * fagan is raging that he is still in college after seeing the planet post about the QA team opening :( | 09:43 | |
| nperry | Quit college | 09:44 |
| fagan | ha | 09:44 |
| fagan | nperry: If only it was that easy, for a start my dad would kill me after paying 1700 this year for college | 09:45 |
| nperry | On second thoughts see it through till end of year | 09:48 |
| nperry | You'll then still have all your limbs | 09:48 |
| fagan | nperry: hopefully | 09:50 |
| * fagan wonders why this and #ubuntu-quality are so quiet at the moment | 11:40 | |
| === kyselejsyrecek is now known as Nethe_The_First | ||
| === Nethe_The_First is now known as Nethe_The_First_ | ||
| === Nethe_The_First_ is now known as Nethe | ||
| === Nethe is now known as kyselejsyrecek | ||
| === fader|away is now known as fader_ | ||
| * ara -> lunch | 13:33 | |
| moustafa | fader_, cr3 : Camembert! | 14:16 |
| fader_ | moustafa: Bouf! | 14:16 |
| fagan | jambon | 15:18 |
| fagan | fader_: ^ good? | 15:18 |
| fader_ | fagan: Heh, I had to look that one up. Mon français est mauvais. | 15:19 |
| fader_ | All I can do is quote song lyrics :P | 15:19 |
| fagan | Hah | 15:20 |
| fagan | It means ham or arm | 15:20 |
| fagan | Depending on context | 15:21 |
| * fagan trys to get in with the IRC greetings lingo | 15:21 | |
| fader_ | fagan: It's all about the foux da fa fa :) | 15:23 |
| fagan | :) | 15:25 |
| fagan | Its actually a good song IMO | 15:26 |
| fagan | Oh fader_ I saw this http://people.canonical.com/~fader/hw-testing/current why cant we have that for hwdb.ubuntu.com? | 15:32 |
| * fagan really wants a public access hwdb from the checkbox results | 15:33 | |
| fagan | But I presume the computers on your list went through harder tests | 15:34 |
| fader_ | fagan: It's a combination of a lot of things that makes it difficult to report on the hwdb :( | 15:36 |
| fader_ | We don't have the same machines being tested on a daily basis, so it's difficult to establish a baseline | 15:36 |
| fader_ | We can run more intensive and/or destructive tests in the lab | 15:37 |
| fader_ | There's a lot of possibility for human error in more widespread testing | 15:37 |
| fagan | Ah | 15:37 |
| fader_ | And unfortunately there's not a great way of extracting the result data in aggregate from hwdb at the moment | 15:37 |
| fagan | Well thats always the risk with community submissions | 15:37 |
| fader_ | The good news is that we all want this data to be more useful and more visible, and cr3 has been on a holy quest to figure a lot of this out :) | 15:38 |
| fader_ | (Not that I'm promising anything on his behalf; just saying that people are thinking about it and working on it :) ) | 15:38 |
| fagan | Well good | 15:39 |
| * fagan wants to be able to broadcast the fact his computer is working fine | 15:39 | |
| === jsalisbury___ is now known as jsalisbury | ||
| cr3 | sbeattie: hey dude, got a minute to discuss qa-regression-testing in mainstream checkbox? | 16:23 |
| sbeattie | sure | 16:25 |
| * sbeattie is still a bit under-caffienated, so may not be entirely coherent | 16:26 | |
| cr3 | sbeattie: I'd like to push the qrt integration into main, but I'm not sure how this should be presented to the community | 16:26 |
| cr3 | sbeattie: qrt has a couple major implications: 500Mb download and destructive | 16:26 |
| sbeattie | by "pushed into main" what do you main? | 16:27 |
| cr3 | sbeattie: so that when you install lucid, you can potentially run the qrt yourself | 16:27 |
| sbeattie | I think the security team has some objections to having it packaged in the regular archive; a daily build style ppa may make more sense. | 16:28 |
| jdstrand | jeez no | 16:28 |
| sbeattie | (packages in the archive get stale and are unchanging) | 16:28 |
| jdstrand | it's huge, not audited and will be hard to maintain | 16:29 |
| sbeattie | see the ubuntu-qa-tools package for a package example that's *way* behind the current bzr tree. | 16:29 |
| jdstrand | maybe a script that pulls down the bzr branch would be ok... | 16:29 |
| cr3 | sbeattie: if you recall, the integration of qrt branches it so there's no packaging implications | 16:30 |
| cr3 | sbeattie: have a look at my branch: https://code.edge.launchpad.net/~cr3/checkbox/qrt | 16:30 |
| cr3 | sbeattie: the integration just consists of suites/qa_regression.txt.in and scripts/qa_regression_suite | 16:31 |
| sbeattie | ah! | 16:31 |
| cr3 | sbeattie: so, the concern is strictly user experience related, ie how should we prevent users from shooting themselves in the foot (or head) by accidentally running the qrt | 16:31 |
| cr3 | sbeattie: I would propose a couple options which can easily be implemented: | 16:33 |
| cr3 | 1. have the qrt suite unselected by default when listing all the suites in checkbox; | 16:33 |
| cr3 | 2. have the qrt suite not appear at all in the list of suites, checkbox would need to pass a command line parameter to present the qrt suite in that list | 16:34 |
| cr3 | personally, since qrt seems to be targetted to a small audience considering its destructive nature, I'd be inclined towards option #2. | 16:35 |
| cr3 | what do you think? | 16:35 |
| sbeattie | cr3: do you ship with other suites that are disabled by default? | 16:35 |
| cr3 | sbeattie: nope, this is a first :) | 16:35 |
| cr3 | sbeattie: typically, those other suites are internal but I see no reason to keep qrt internal | 16:35 |
| cr3 | but I do see a reason to keep it disabled by default for obvious reasons | 16:36 |
| cr3 | sbeattie: what would you say if I added the option --we-love-sbeattie to enable the qrt suite? | 16:36 |
| sbeattie | something like that (--danger-will-robinson-danger) would be fine. | 16:37 |
| sbeattie | mago is packaged independently, correct? | 16:38 |
| cr3 | sbeattie: nah, I do the same as for qrt: the script branches the latest code. except that I only use mago internally | 16:38 |
| cr3 | sbeattie: typically, I appreciate how test suites don't necessarily benefit from being packaged in order to always use the latest code. so, I privilege referring to the rcs repositories | 16:39 |
| cr3 | sbeattie: that's also what I do with autotest (even though it's been packaged for RH) and ltp (some of which has been packaged) | 16:40 |
| kees | cr3: qrt is not appropriate to be packaged -- it changes frequently and is highly destructive to a system. | 16:40 |
| * sbeattie assumes that if mago isn't destructive now, it will be someday; changing configs, putting windows in odd states (e.g. --geometry 6000x100), etc.) | 16:40 | |
| kees | whenever qrt changes, all prior releases would need to be SRU'd. it'd be crazy | 16:40 |
| cr3 | kees: you can package it as "autodestruct-button" | 16:40 |
| sbeattie | kees: yep, we're all agreed on that. | 16:41 |
| kees | cr3: just download it from bzr, and use the bzr revision for tracking. | 16:41 |
| jdstrand | what's wrong with providing a script to download it? | 16:41 |
| cr3 | kees: done already | 16:41 |
| kees | which is done already? | 16:41 |
| jdstrand | and have checkbox use that | 16:41 |
| cr3 | kees: the concern is not that, it's how this is presented to an enduser | 16:41 |
| sbeattie | kees: the script for downloading. | 16:41 |
| cr3 | kees: qrt is already integrated by branching | 16:41 |
| kees | qrt doesn't make sense for enduers. it is not a _system_ testing tree (you want system tests to go to users). it is a _software_ testing tree, used by the distro to prove out the software before we release. | 16:42 |
| cr3 | sbeattie: man, kees and jdstrand are lagging on our conversation :) | 16:42 |
| jdstrand | heh | 16:42 |
| jdstrand | sorry, this comment was a bit scary: | 16:42 |
| jdstrand | 10:26 < cr3> sbeattie: I'd like to push the qrt integration into main | 16:42 |
| cr3 | so, what would you guys think about this: qrt is integrated in checkbox by having a script that branches qrt and runs all those tests which can be automated. however, the qrt suite is blacklisted by default and endusers are never exposed to it. so, in order to run the suite, you need to remove the blacklist either in the configuration file or at the command line. | 16:45 |
| jdstrand | that sounds sane. as long as it isn't discoverable via the gui and appropriate warnings are in place around the config option or in the man page/help | 16:46 |
| kees | sure. as long as the internal testing uses qrt | 16:46 |
| cr3 | another option would be to provide a separate package, such as checkbox-qrt, which just provides the qrt integration scripts which would branch as described above. my concern is that it would seem overkill to just create a package for that | 16:46 |
| cr3 | jdstrand: agreed | 16:46 |
| cr3 | kees: yep, the blacklist would simply be overridden when performing internal testing | 16:47 |
| cr3 | kees: the advantage is that if there's any doubt about the internal testing, then all the tools available to reproduce the tests being done internally are readily available to everyone | 16:47 |
| cr3 | sbeattie: based on the above, would you mind being my sounding board to validate that the constraints agreed upon are implemented properly? | 16:48 |
| cr3 | s/constraints/requirements/ | 16:49 |
| sbeattie | cr3: that all sounds sensible to me, and I'd be happy to be the sounding board. | 16:50 |
| cr3 | sbeattie: cool, I'll get this done shortly so that we can get the package reviewed today | 16:50 |
| sbeattie | cr3: awesome! | 16:51 |
| cr3 | sbeattie: this should also make your life easier when integrating additional tests from qrt: you will only have to work on checkbox rather than an internal client which depends on checkbox, ie fewer levels of indirection | 16:52 |
| cr3 | sbeattie: I have a ppa building checkbox with qrt integration which should be ready soon: https://edge.launchpad.net/~cr3/+archive/ppa/+packages | 19:06 |
| cr3 | sbeattie: in order to enable the qrt suite, either change /etc/checkbox.d/checkbox.ini (which can be preseeded) or start checkbox-gtk with the option --config='checkbox/plugins/suites_prompt/blacklist=' | 19:06 |
| sbeattie | cr3: okay, thanks. | 19:06 |
| cr3 | ogasawara: hi there, do you happen to know of a script that sets the acpi wakealarm stuff? | 20:32 |
| cr3 | sbeattie: I'm sorry for the delay in building the qrt checkbox package, it seems like ppa building is really slow today | 20:33 |
| sbeattie | no worries. | 20:34 |
| cr3 | what does "pm" mean in "pm-suspend" for example? | 20:34 |
| fagan_ | power manager | 20:35 |
| fagan_ | :) | 20:35 |
| cr3 | fagan_: man, now I feel like quite the idiot :) | 20:36 |
| * fagan_ is a super hero his power knowing random facts to pull out of the hat when needed | 20:38 | |
| fader_ | cr3: /usr/share/checkbox/scripts/suspend_test references wakealarm | 20:39 |
| fader_ | No checkbox test currently uses it but I believe the script supports it | 20:40 |
| cr3 | fader_: ok, looking over some of the additiona-tests branches: some tests were broken and others could use a cleanup | 20:43 |
| cr3 | if I can have the pm.py script in checkbox-oem use the existing suspend_test, I think that'd be a win | 20:45 |
| fader_ | cr3: Yeah, the suspend_test script has a lot of sexy features and I believe it is pretty well tested | 20:45 |
| sbeattie | doesn't it also have issues due to buggy system acpi implementations? | 20:47 |
| * sbeattie has a vague recollection of complaints that post running the wakealarm tests, some laptops would spuriously wake up during non-testing suspend events) | 20:49 | |
| cr3 | sbeattie: it also seems that suspend_test is implicitly interactive | 20:50 |
| cr3 | oh wait, there's an --auto flag! | 20:50 |
| ogasawara | cr3: I checked in a wakealarm test script in my checkbox-certification branch | 21:41 |
| ogasawara | cr3: just need that branch reviewed (sent you email) | 21:41 |
| cr3 | ogasawara: cool, any particular reason why there's a new script instead of reusing suspend_test script? | 21:42 |
| ogasawara | cr3: I saw it as suspend_test should depend on the wakealarm script passing first | 21:45 |
| ogasawara | cr3: but you could just run suspend_test too | 21:45 |
| cr3 | ogasawara: ah, so if the hardware doesn't support wakealarm, don't even bother to run the suspend_test, right? | 21:46 |
| ogasawara | cr3: right | 21:48 |
| cr3 | ogasawara: would it make sense to fold that logic into the suspend_test itself? | 21:49 |
| cr3 | instead of having to maintain two scripts? | 21:49 |
| cr3 | I would imagine that the same logic could be reused by the suspend_test to barf if wakealarm is not supported by the hardware | 21:50 |
| ogasawara | cr3: yup, that would work too | 21:50 |
| moustafa | fader_, cr3, I'm off for the week-end | 22:00 |
| moustafa | take care! | 22:00 |
| fader_ | moustafa: Ciao! | 22:00 |
| * fader_ is off for the weekend. | 22:07 | |
| fader_ | Take it easy everybody. | 22:08 |
| === fader_ is now known as fader|away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!