12:00:18 <E-P> #startmeeting Mer QA meeting 24/5/2012
12:00:18 <MerBot> Meeting started Thu May 24 12:00:18 2012 UTC.  The chair is E-P. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
12:00:18 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01:12 <E-P> Today's agenda: http://www.mail-archive.com/mer-general@lists.merproject.org/msg00508.html
12:01:47 <E-P> #topic Current status
12:02:12 <lbt> o/
12:02:53 <E-P> From my side not much to report, I have played with the nemo virtual image and filed a task about connman
12:03:16 <E-P> https://bugs.merproject.org/show_bug.cgi?id=335
12:03:40 <E-P> lbt: you are working with the copyproj?
12:03:51 <lbt> I have been
12:04:07 <lbt> I did a report on it in the release management meeting on tuesday
12:04:18 <lbt> summary ... it makes my eyes bleed
12:04:30 <lbt> so I took a break and am working on SDK/Tools
12:04:50 <E-P> ok :)
12:04:51 <lbt> objective is to be able to 'release' Tools repos
12:05:24 <E-P> what do you mean by release?
12:06:07 <lbt> run ./createrelease Mer:Tools <relnum> => http://releases.merproject.org/releases/<relnum>
12:06:56 <E-P> :nod:
12:07:00 <lbt> I am tidying up Stskeeps' _wonderful_ bash/python/make experiment^H^H^H^H^H code
12:07:58 * lbt wonders if he can hire some pedestrians to form flash-mobs during his driving lessons as payback
12:08:06 <lbt> anyhoo
12:08:25 <lbt> I would like to finish this work by the end of the weekend
12:08:33 <lbt> and then get back to OBS/copyproj
12:09:08 <lbt> Until then IMG is working fine and it should be possible to create images and use them manually for QA
12:09:12 <E-P> #info lbt is working on releasing Tools repos
12:09:56 <E-P> alright, if nothing else lets move on
12:11:07 <E-P> #topic QA tools and OBS
12:11:51 <E-P> Sage had some comments to this topic
12:11:58 <E-P> just a sec, I will paste them
12:12:17 <E-P> < Sage> 2) I would separate the QA tools to Mer:QA:Tools or similar (Mer:Tools:QA is not good as that mixes with Mer:Tools:Testing on the same level). Also I would probably try to drop the native host support and would give that mainly via Mer SDK as then it would mean that we don't need to worry about distributions having same package with different patches installed and that we would break the host distro functionality.
12:12:50 <E-P> I also agree with him
12:13:13 <E-P> timoph made a comment about adding QA tests under Mer:QA:Tests
12:13:19 <lbt> why are testing tools for the SDK discrete from other tools for the SDK ?
12:14:04 <lbt> I do think there should be a QA tools area for development though
12:14:08 <phaeron> I am working in parallel on taking the server parts of this stuff so we can have some form of QA automation both for mer and vendors
12:14:35 <phaeron> currently that's here https://build.pub.meego.com/project/monitor?project=Project%3ATools%3ATesting
12:14:37 <lbt> yeah - I also think that we have an SDK/device/server split
12:15:04 <phaeron> yes so I am taking the server  part , while Sage is working on the SDK part
12:15:10 <lbt> I expect SDK==device=> mer target
12:15:41 <lbt> phaeron: makes sense ... and I can see the sense in managing that by itself if needed
12:16:05 <phaeron> yes that project was an initial dumping ground for OTS
12:16:07 <E-P> lbt: so you would like to have all tools in one repo?
12:16:20 <phaeron> splitting it up should make that distinction and then  we can nuke that project
12:16:45 <lbt> E-P: I don't yet see a reason to split testing tools from other tools wrt SDK/device
12:17:06 <E-P> ok
12:17:20 <phaeron> lbt: from building and installing point of view it could be easier to split the tools
12:17:29 <phaeron> it's going to contain a lot of ruby stuff
12:17:35 <phaeron> (the QA part)
12:17:43 <E-P> yep, the qttas requires them
12:17:47 <lbt> *nod*
12:17:51 <phaeron> tdriver specifically
12:18:16 <lbt> I think it makes a great deal of sense to have Tools:Devel:QA
12:18:39 <lbt> and Tools:Devel:QA:Testing
12:19:26 <lbt> then the QA team work with those 2 repos ... when they're happy they push to Tools[:Testing] for wider testing/release
12:19:43 <phaeron> yeah that should make releasing easier
12:20:08 <lbt> Tools:Devel:QA can be Project:OTS if you prefer
12:20:09 <E-P> and only tools that work in the SDK should be pushed to Tools[:Testing]?
12:20:29 <lbt> E-P: yes (possibly device too...)
12:20:43 <E-P> yes, both
12:21:08 <lbt> phaeron: opinion? Am I agreeing with you?
12:21:19 <E-P> so tools like OTS should then be in Tools:Devel:QA
12:21:20 <phaeron> yes
12:21:20 <E-P> ?
12:21:46 <lbt> E-P: OTS is server-side - so builds against suse/debian or something
12:21:50 <phaeron> well whether the project is called OTS or not is not the point
12:22:00 <phaeron> it could be a part of MINT imho
12:22:01 <lbt> nod*
12:22:04 <lbt> agree
12:22:31 <lbt> we should not split unless there's a strong reason IMHO
12:23:00 <lbt> day-to-day hacking areas for teams - that's different
12:23:27 <phaeron> ok
12:23:27 <E-P> sounds good for me
12:23:31 <lbt> and I/we shouldn't use Tools:Testing as a hacking area :/
12:25:11 <lbt> phaeron: so do you want to make Mer:Tools:Devel:QA and M:T:D:Q:Testing
12:25:23 <phaeron> that's Sage
12:25:32 <phaeron> he  has admin on Mer: ?
12:25:34 <lbt> OK, he's not admin
12:25:38 <lbt> afaik
12:25:40 <phaeron> ah
12:25:40 <lbt> maybe
12:26:24 <phaeron> you probably meant Mer:Tools:Devel:QA and Mer:Tools:QA:Testing ?
12:26:52 <E-P> phaeron: so the Project:Tools:testing is obsolete?
12:26:53 <phaeron> or *QA:Devel and *:QA:Testing
12:27:19 <phaeron> E-P: going to be , I am using it to fix building of stuff for the servers
12:27:32 <lbt> phaeron: I'm not sure how best to use it
12:27:35 <E-P> good
12:27:54 <lbt> I like to have a subproj called :Testing which I can upload random stuff to
12:28:04 <lbt> then when it's OK, push to the main proj
12:28:05 <phaeron> and once sage is done preparing he'll move the stuff to the Mer:Tools area
12:28:42 <lbt> so I meant Mer:Tools:Devel:QA and Mer:Tools:Devel:QA:Testing
12:28:51 <lbt> those are 'private' to E-P and team
12:29:06 <lbt> really it's up to E-P what goes under Mer:Tools:Devel:QA
12:29:06 <phaeron> who's team :)
12:29:24 <E-P> those projects are good for me
12:29:26 <lbt> :)      QA team
12:29:33 <E-P> the great QA team :)
12:29:55 <phaeron> anyway I'll fold server parts to MINT once I am done
12:30:09 <lbt> nb... one reason I'm suggesting this is to mimic how I think it's done in a larger organisation
12:30:13 <E-P> what is the OBS project for MINT?
12:30:24 <phaeron> Project:MINT:Testing
12:30:50 <lbt> I'd suggest that Mer:Tools:Devel:QA *could* build against debian/suse in a selective way too
12:31:15 <E-P> lbt: yes, and server side tools could be pushed to MINT project then
12:31:22 <phaeron> you have to convince sage :D
12:31:28 <lbt> I think of Mer:Tools:Devel:QA as a 'team area'
12:31:59 <lbt> maybe it shouldn't be under Mer:Tools ... open to sugestions
12:33:35 <lbt> E-P: it kinda depends how tied the code is
12:33:55 <E-P> it could be own project
12:34:28 <E-P> we do anyway server side and device side tools and then we could push tools to correct testing repo's
12:34:34 <lbt> the more projects there are, the more places you need to look to get a feel for wtf is going on :)
12:35:02 <E-P> yep, that is true, that's why we are trying to have clear rules
12:35:12 <E-P> and document them to wiki
12:35:24 * phaeron hates wiki
12:35:51 <E-P> ok, how about the tests then, should they we only under the QA project?
12:36:28 <phaeron> I think those should be nearer to core
12:36:35 <lbt> I think tests should be very close to code
12:36:36 <phaeron> if they test core
12:36:54 <phaeron> yes near the project / code they test
12:37:06 <phaeron> middleware test cases live near CE:MW
12:37:11 <lbt> in my 'release' steps I break out 'debug' packages to a discrete area
12:37:24 <phaeron> ux test cases live near CE:UX
12:37:28 <phaeron> etc ..
12:37:29 <lbt> we could do the same for tests
12:38:20 <E-P> should the tests have own subproject under those projects?
12:38:29 <E-P> eg. CE:MW:Tests
12:38:58 <phaeron> they probably build in the same project , but get split out during release repo creation like lbt suggested
12:39:07 <phaeron> but ymmv
12:40:36 <E-P> and it won't get too messy if the tests packages are in the same project?
12:41:22 <phaeron> some  packages already build -tests pacakges
12:41:24 <lbt> I'd like to see what tests we have
12:41:35 <lbt> I can think of several kinds
12:41:52 <lbt> tests that are part of upstream code
12:41:59 <lbt> ruby/perl does this a lot
12:42:32 <lbt> tests specific to a tarball and alongside upstream code
12:42:46 <lbt> kinda like we do with patches
12:43:23 <lbt> tests that run against 2+ tarballs and don't really belong to either
12:43:57 <lbt> that kinda scales to include image tests I think
12:44:40 <lbt> so I think 1+2 go into the code project
12:44:52 <lbt> 3 needs a QA:Tests project somewhere
12:45:13 <lbt> consider ^^ a strawman :)
12:45:35 <lbt> doorbell... bbiam
12:46:47 <phaeron> you don't need to have tests for 2 tarballs in a separate project , it could be in the  same project but in a separate package
12:47:13 <E-P> hmm.. I would like to have tests like phaeron mentioned, Core, MW and UX
12:47:33 <E-P> not spreading them around
12:47:39 <phaeron> so if we you are packaging a tdriver based testcase for lockscreen , it will probably be in CE:UX:MTF
12:48:04 <E-P> yes, because it is designed for MTF
12:48:33 <phaeron> testing package for chat middleware that implements a dbus interface could be telepathy or peregrine so it would live  in CE:WM
12:48:43 <phaeron> imho
12:48:59 <E-P> yep
12:49:26 <E-P> and for core, connman, bluez, ofono test packages
12:49:29 <lbt> back
12:50:00 <phaeron> makes it also easier to include the test packages in an image during a request that promotes such a package
12:50:26 <phaeron> and using patterns in repos that contain such test packages
12:50:52 <E-P> lbt: what do you think about that? do you see something that might not work?
12:51:08 <phaeron> ie put @MW_TEST in a nemo image ks and you have a QA  image
12:51:27 <lbt> E-P: I think we're in agreement
12:52:00 <phaeron> we agree on your 1+2 but not on  your 3
12:52:09 <lbt> basically instead of QA:Tests ... put them in CE:MW
12:52:16 <phaeron> yes
12:52:18 <E-P> yep
12:52:52 <lbt> I suggest that you 'release' tests to that location though
12:53:19 <lbt> it kinda depends how the teams work - and I'm thinking about how it scales up to a company
12:53:54 <phaeron> collecting them in a place before pushing them to a respective project is ok too
12:54:24 <phaeron> in that case  could be  intermediate home area or devel area or dedicated area
12:54:41 <lbt> I suggest we don't overthink it.. try it and review it
12:54:53 <lbt> bearing in mind we may change things around
12:55:07 <E-P> yes, usually it is good that start with something and then change it
12:55:15 <phaeron> yes and we don't have that many anyway , yet , so release early and release often
12:55:34 <phaeron> instead of waiting till we have too many and changing is difficult
12:55:35 <E-P> I would say then, that we will have Mer:QA project, under that having Tools, and Tests
12:56:32 <lbt> and Mer:QA:Tools is promoted to Mer:Tools[:Testing] for releasing?
12:56:54 <E-P> yes
12:57:13 <lbt> so that's instead of Mer:Tools:Devel:QA
12:57:19 <E-P> yes
12:57:22 <lbt> OK
12:57:34 <E-P> I think it is simpler like that
12:57:50 <lbt> I'm not unhappy with it
12:58:04 <E-P> phaeron: how about you?
12:58:13 <lbt> the :Devel project name never really made sense to a lot of people :)
12:58:21 <phaeron> anything to get started :)
12:58:21 <E-P> (I have to go soon, so let's skip the 3rd topic and move it to the next week)
12:58:34 <lbt> OK
12:58:59 <E-P> #info Not separating QA tools and Mer tools
12:59:15 <E-P> #info QA Tools that work in the SDK or in a device are allowed to push to Tools:Testing
12:59:23 <E-P> #info Server side tools to Project:MINT:Testing
12:59:32 <E-P> #info Creating OBS projects for QA team, Mer:QA
12:59:43 <E-P> #info Project:Tools:Testing is going to be obsolete
13:00:26 <E-P> #info Releasing QA tests to Mer:QA:Tests and then pushing the tests to a respective project
13:00:34 <E-P> #info Sage is working on the device side tools
13:00:37 <E-P> #info phaeron is working on the server side tools
13:00:53 <E-P> I think that was all, something missing?
13:01:15 <phaeron> good job :D
13:01:17 <lbt> now we're thinking of promotion we need to add acceptance criteria for the tools and tests
13:01:28 <E-P> who can create the QA project?
13:01:30 <lbt> for another agenda point
13:01:40 <E-P> lbt: I will add that to the topic list
13:02:03 <E-P> #info We need to add acceptance criteria for the tools and tests
13:02:10 <lbt> I'll make the projects and make E-P own them
13:02:17 <E-P> thanks
13:02:29 <E-P> #action lbt Will create Mer:QA project to OBS
13:03:00 <E-P> ok
13:03:13 <E-P> #topic Image for test automation
13:03:23 <E-P> #info moved to the next QA meeting
13:03:45 <E-P> I have to run (cycle), thanks for coming
13:03:51 <lbt> ty
13:03:55 <phaeron> bye
13:04:16 <E-P> #endmeeting