[00:05] <cr3> I be out
[07:28] <ara> morning!
[16:03] <plars> ara: so... no meeting then?
[16:04] <ara> it is at 16:30UTC
[16:04] <ara> so in 1 hour and a half
[16:05] <ara> plars: ^
[16:05] <ara> plars: what did you understand from my email?
[16:06] <plars> ara: oh, I'm not awake yet!
[16:06] <ara> plars: ;-)
[16:06]  * plars suddenly realizes that 1500 is in fact, NOT > 16:30
[16:06] <plars> heh
[16:07] <ara> plars: yes, these meetings around the globe are confusing
[17:09] <eeejay> hello lovely clowns
[17:18] <ara> morning eeejay!
[17:18] <eeejay> hi ara, nice to catch you awake :)
[17:18] <ara> eeejay: I am missing you in my time zone
[17:19] <eeejay> :)
[17:30] <ara> hello heno
[17:30] <heno> hey ara
[17:31] <ara> cgregan, jcollado, eeejay, plars: meeting ping
[17:32] <jcollado> ara: pong
[17:32]  * plars is (mostly) awake
[17:32]  * eeejay is here
[17:32]  * heno waits for the wiki page to load
[17:33] <jcollado> eeejay: Let's talk here, review messages in launchpad are getting messy
[17:33] <eeejay> jcollado: sure :)
[17:34] <jcollado> eeejay: So would you prefer to have two different options? Filtering by file name and filtering by name in the XML file?
[17:34] <eeejay> jcollado: so before your changes, I was able to run mago from the build directory. This made me very happy.
[17:34] <eeejay> jcollado: yes!
[17:34] <heno> For the general audience in the chan: we're starting a weekly desktop testing meeting in here
[17:35] <heno> https://wiki.ubuntu.com/Testing/Automation/Desktop/Meetings
[17:35] <jcollado> eeejay: OK. I can do that.
[17:35] <ara> jcollado, eeejay: can you talk about that a bit later, please? or add an item to the agenda ;-)
[17:35] <jcollado> ara: OK
[17:36] <heno> indeed let's start
[17:36] <heno> eeejay: I just added an item for you to catch everyone up on your desktop test deployment work
[17:37] <cgregan> do we have a mootbot here?
[17:37] <heno> #startmeeting
[17:37] <heno> ?
[17:37] <heno> no bot :(
[17:37] <eeejay> heno: you mean the first agenda item? yeah, i saw that
[17:38] <heno> eeejay: right, you've made some checkbox changes
[17:38] <eeejay> heno, yup
[17:38] <eeejay> i backed out of most of them
[17:38] <eeejay> just for the sake of simplicity, it would still be nice to merge them in
[17:38] <eeejay> but we don't want that to block
[17:38] <eeejay> right?
[17:39] <heno> and we agreed the tests would go in the checkbox-qa package
[17:39] <eeejay> yes
[17:39] <eeejay> i plan to talk to schwuk about it tomorrow
[17:39] <heno> what would be blocked by that?
[17:39] <ara> eeejay: is there any documentation about the work your doing? meeting minutes or something like that
[17:40] <eeejay> heno: pending checkbox core changes would block the mago plugin
[17:40] <eeejay> heno: if the plugin depended on the changes
[17:40] <heno> ok, I see
[17:41] <eeejay> ara: https://wiki.ubuntu.com/QATeam/Specs/DailyDesktopTesting
[17:41] <eeejay> so the plugin should be complete this week
[17:41] <ara> eeejay: thanks
[17:41] <eeejay> next week is checkbox-qa, i guess
[17:41] <eeejay> and after that deployment
[17:42] <eeejay> where cr3 will need to hold my hand
[17:42] <ara> eeejay: and is the changes your making on a public branch?
[17:42] <eeejay> ara: https://code.launchpad.net/~eeejay/+junk/checkbox-mago
[17:42] <heno> eeejay: who is setting up checkbox-qa? cr3 or schwuk?
[17:42] <eeejay> heno, i understood from our chat that schwuk is, no?
[17:42] <ara> eeejay, heno: and yet another question? is checkbox-qa a package meant to be in karmic, or just an internal thing?
[17:42] <schwuk> heno: I'd planned to, with input from cr3
[17:43] <heno> ok, great
[17:43] <schwuk> ara: in universe for karmic
[17:43] <eeejay> schwuk, i hope we could talk about it at tomorrow's meeting?
[17:43] <heno> ara: in karmic
[17:43] <ara> schwuk, heno: ta
[17:43] <schwuk> eeejay: sure
[17:43] <plars> and what is the purpose of checkbox-qa? this is the first I've heard about it, is it to satisfy the requirements for daily desktop testing?
[17:43] <eeejay> speaking of.. is mago going into karmic universe?
[17:43] <heno> https://wiki.ubuntu.com/QATeam/Specs/CheckboxExpandTestCoverage
[17:44]  * heno afk
[17:44] <plars> ok, so is it just a temporary branch to do this, that will later be merged back into checkbox trunk? or is it assumed it will always be a separate project?
[17:45] <ara> eeejay: mmm, no idea. We haven't planned that yet.
[17:46]  * eeejay don't know
[17:46] <ara> eeejay: is there a point of having checkbox-qa in karmic and not having mago in karmic?
[17:46] <eeejay> ara: well, it seems like mago will be a checkbox-qa dependency, so i am just hoping it's packaged somewhere.
[17:47] <schwuk> plars: https://wiki.ubuntu.com/QATeam/Specs/CheckboxEnhancements, about halfway down.
[17:47] <eeejay> although I would hate to see us constrained to the distro's schedule
[17:47] <eeejay> don't want jcollado to be held back :)
[17:48] <jcollado> eeejay: Thanks
[17:48] <ara> eeejay: then a package is needed, indeed. I can take care of that task
[17:48] <schwuk> eeejay: if checkbox-qa ends up in a PPA because of Mago, we can deal with that
[17:48] <schwuk> Or (temporarily) have a checkbox-qa-mago until Mago is in the archives
[17:48] <schwuk> But I'd like to avoid that if possible
[17:48] <eeejay> all seem like viable alternatives
[17:49] <schwuk> I'll add about the split package/PPA into the spec, just so it's captured.
[17:49] <eeejay> as we discussed at UDS, the additional non-default packages that are needed for testing should not be installed as packages, but be run from CWD
[17:49]  * heno back
[17:49]  * eeejay is talking about daily testing
[17:50] <eeejay> not community and user checkbox usage
[17:50] <schwuk> eeejay: got you
[17:51] <heno> thanks eeejay
[17:51] <eeejay> so that's my report.
[17:51] <heno> any other topics?
[17:51] <eeejay> jcollado's branch
[17:51] <ara> Suite discovery changes -- jcollado
[17:51] <heno> (is 30 min too short for this meeting?)
[17:51] <jcollado> Just wanted to clarify how to remove the roadblocks for merging
[17:51] <eeejay> jcollado's branch is important for mago checkbox plugin
[17:51] <cr3> eeejay: me love hand holding long time
[17:52] <eeejay> :)
[17:52] <jcollado> Let's talk about the XSL file
[17:52] <cr3> jcollado: roadblocks for merging? have you submitted some branch for review?
[17:52] <jcollado> I think it would be a good idea to have a unique XSL file
[17:53] <ara> cr3: he's talking about mago
[17:53] <jcollado> that is easy to locate
[17:53] <jcollado> to avoid the problems that you, eeejay, are having
[17:54] <eeejay> jcollado: this is one alternative
[17:54] <jcollado> Maybe in a data subdirectory in the python module
[17:54] <eeejay> actually two:
[17:54] <jcollado> could be a good place
[17:54] <eeejay> 1. have MAGO_XSL in addition to MAGO_PATH
[17:55] <eeejay> 2. instead of MAGO_PATH, have MAGO_SHARE that is not a ":" separated list, just one path
[17:55] <eeejay> 2.1. that points to /usr/local/mago/share
[17:55] <eeejay> ^ $(prefix)/share/mago
[17:56] <jcollado> MAGO_PATH is for test suite discovery, but XSL file I think isn't part of the test cases it's something that should be part of the library
[17:56] <eeejay> jcollado: than maybe MAGO_SHARE in addition to MAGO_PATH
[17:57] <cr3> jcollado: couldn't MAGO_PATH be inferred by MAGO_SHARE? ie, something like $(MAGO_SHARE)/tests
[17:57] <jcollado> cr3: The idea is that MAGO_PATH contains multiple directories
[17:57] <jcollado> cr3: with test cases located anywhere
[17:57] <eeejay> jcollado: i kind of like that too
[17:58] <cr3> jcollado: gotcha, hence what you said about: MAGO_SHARE that is not a ":" separated list, just one path
[17:58] <jcollado> cr3: However, the XSL file is unique
[17:58] <cr3> s/you/eeejay
[17:58] <eeejay> how about this
[17:58] <jcollado> Maybe it's better to have MAGO_PATH and MAGO_XSL
[17:58] <eeejay> MAGO_PATH and MAGO_SHARE, where by default:
[17:58] <cr3> MAGO_SHARE seems reciprocal to CHECKBOX_SHARE, which seems to have worked well so far
[17:59] <eeejay> MAGO_PATH = $(MAGO_SHARE)/tests
[17:59] <cr3> eeejay: I like that
[17:59] <heno> ok, we need to wrap up, the main QA meeting is starting now in #ubuntu-meeting
[18:00] <heno> (but feel free continue here)
[18:00] <jcollado> I don't really like to have the XSL file depend on an environment variable
[18:01] <jcollado> It's supposed to be something that isn't going to change frequently
[18:01] <jcollado> Is not as the test cases that someone may try out different things
[18:02] <cr3> jcollado: I've found that having an environment variable like that makes it easier to be able to run the application from the source directory and then, when building the package, simply change that variable so that it can run from an installed package
[18:03] <eeejay> jcollado: the env variable should be an override to the defaults
[18:03] <eeejay> jcollado: they shouldn't be mandatory, nobody should know/use them
[18:03] <eeejay> jcollado: unless they are developing, like us
[18:04] <jcollado> Ok, maybe we can use MAGO_SHARE to point to the shared test cases (and the XSL file)
[18:05] <jcollado> and MAGO_PATH for the extra test cases
[18:05] <jcollado> MAGO_SHARE: single directory
[18:05] <jcollado> MAGO_PATH: multiple directories
[18:05] <jcollado> Would that be ok for you?
[18:07]  * jcollado assumes everybody agrees
[18:08] <cgregan> :-)
[18:12] <sbeattie> cr3: that's just cause the IS team is out to get you. :-)