12:20:32 <Stskeeps> #startmeeting Mer QA meeting 5/7/2012
12:20:32 <MerBot> Meeting started Thu Jul  5 12:20:32 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
12:20:33 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:21:07 <Stskeeps> #topic Status/progress
12:22:12 <Stskeeps> #info continued work on copyprj, getting closer to a workable situation
12:22:17 <Stskeeps> (end)
12:23:03 <Stskeeps> others who has done something useful in the QA area or attempts to use our QA tools who'd like to share their experiences?
12:23:34 <iekku> o/
12:23:48 <iekku> i have one question
12:24:11 <lbt> #info spent some time setting up QA tools on ExoPC - noticed lots of small problems and general lack of HOWTO docs.
12:24:15 <lbt> #
12:24:25 <iekku> does mer provide a mechanism to collect debug information on device?
12:24:54 <iekku> and if not, would it be something our qa should think about
12:24:56 <Stskeeps> i've started some patches to provide 'tracing' packages, which causes mer core level system daemons to start debugging mode
12:24:58 <lbt> #info I plan to describe extending a .ks to support testrunner/eat.
12:25:16 <iekku> Stskeeps, oh, nice
12:25:18 <Stskeeps> #info i've started some patches to provide 'tracing' packages, which causes mer core level system daemons to start debugging mode
12:25:29 <Stskeeps> #info http://wiki.maemo.org/Documentation/devtools/maemo5/sp-rich-core is a tool that can be used to make less fat core dumps
12:25:38 <Stskeeps> there's a task bug for packaging this
12:25:44 <lbt> #info I have some basic/hacky .ks script support for enabling wifi-on-boot for Mer-core devices
12:26:19 <lbt> (ie embedding the SSID/passphrase into the .ks so an automated image can test over wifi)
12:27:11 <Stskeeps> we should alternatively look at connman's config files, too http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=doc/config-format.txt;h=4f768325022e41629cc59d851afbdcfe62a1c4f5;hb=HEAD
12:27:28 <lbt> iekku: it may be worth writing a "deviceinfo" script that will do rpm -qa and other stuff
12:27:51 <lbt> do suse or fedora have anything?
12:27:59 <Stskeeps> lbt: they use ABRT mostly
12:28:03 <Stskeeps> which isn't good for our level
12:28:18 <lbt> OK
12:29:43 <Stskeeps> lbt: so one action is to have testrunner-ui inside Mer:Tools, i presume?
12:29:49 <Stskeeps> what other things are in 'spread out on too many repos'?
12:29:53 <lbt> almost done
12:29:57 <lbt> it's in M:T:T
12:29:59 <Stskeeps> ok
12:30:11 <lbt> eat stuff in your home
12:31:12 <Stskeeps> (where did i have eat stuff?)
12:31:26 <lbt> http://repo.pub.meego.com/home:/stskeeps:/tools-testing-eat/Mer_Core_i586/
12:31:31 <lbt> could be old
12:31:40 <lbt> I was just in "make it work" mode
12:31:41 <Stskeeps> ah, that's just a testcase
12:31:43 <iekku> lbt, ok thanks :)
12:32:04 <Stskeeps> lbt: zypper in "@Testing tools" kind of thing, maybe?
12:32:05 <lbt> Stskeeps: yes, it made me think we need a repo for tests
12:32:06 <Stskeeps> package group
12:32:16 <lbt> Stskeeps: would make sense
12:32:31 <Stskeeps> for SDK, that is
12:32:44 * lbt tries to recall decision/discussion on Mer:QA stuff
12:33:04 <lbt> and wonders if it shouldn't all just go in Mer:Tools until there's a reason to change
12:34:28 <Stskeeps> well, it should probably be release-able alongside mer core, but that's a different story
12:34:30 <lbt> one thing I'm finding a pita here (probably more a release-mgmt issue) is comparing Mer:Tools and Mer:Tools:Testing and a named release to see wtf versions exist in each
12:34:50 <Stskeeps> well, it's you who own those areas..
12:34:50 <Stskeeps> :P
12:35:08 <lbt> yeah - it's back to REVS ... and that's scary
12:35:18 <Stskeeps> can't you just do age old Trunk and Trunk:Testing though?
12:35:25 <Stskeeps> ie, <link project="Trunk" />
12:35:32 <Stskeeps> and sr-and-remove-on-accept
12:36:22 <lbt> that helps to know that packages are in need of promotion
12:36:55 <lbt> could be enough for a while
12:36:57 <lbt> anyhow
12:37:21 <Stskeeps> so, what wiki pages do we need to make to make people understand EAT and testrunner?
12:37:46 <lbt> well, I'm starting to write something for some HA adaptations
12:38:02 <lbt> and I'd like to reference that in the EAT/TR docs
12:38:15 <Stskeeps> makes sense
12:38:20 <lbt> so that'll cover "getting it installed"
12:38:23 <Stskeeps> eat-device only provides the generic core stuff
12:38:26 <Stskeeps> and needs a HA part
12:38:28 <lbt> (to the device)
12:38:31 <lbt> yeah
12:38:42 <lbt> so we need host-side install to SDK
12:38:51 <lbt> and then host/device config
12:39:26 <lbt> that gets us to manual TR-ui level
12:39:55 <lbt> then I think we'd like to see BOSS driven QA
12:40:06 <Stskeeps> sure
12:40:17 <Stskeeps> that's coming with release process, so
12:40:18 <lbt> that probably results in some kind of need for QA results store
12:40:25 <Stskeeps> qa-reports.*
12:40:29 <lbt> yep
12:43:12 <lbt> what happened to the system that automatically ran the TR tests?
12:43:43 <lbt> OTS
12:45:05 <Stskeeps> http://meego.gitorious.org/meego-quality-assurance/ots
12:46:28 <lbt> so really not much at all
12:47:13 * lbt also looks at the TDriver stuff in #nemobile earlier
12:47:17 <lbt> and ruby
12:47:46 <lbt> If we do that then I want a discrete Mer:Ruby project - we can't mix that into Tools - too painful
12:51:01 * lbt wonders if there's a parade on somewhere that everyone is watching....
12:51:37 <Stskeeps> sorry, drifted away to the clouds moving outside
12:51:55 <lbt> yeah, QA is exciting isn't it :)
12:52:06 <Stskeeps> ok, so any #action's to register?
12:52:50 <lbt> do we have a task list?
12:53:08 <lbt> so we can prioritise if anything blocks
12:53:29 <lbt> I can take an action to do the HA and .ks side of EAT
12:53:48 <Stskeeps> ok, task bug then
12:54:07 <lbt> but in general I was wondering if QA should have a short-term roadmap/plan
13:56:29 <lbt> Stskeeps: you may want to endmeeting :)
13:56:43 <lbt> clouds again?
13:57:09 <Stskeeps> #endmeeting