12:00:18 #startmeeting Mer QA meeting 27/09/2012 12:00:18 Meeting started Thu Sep 27 12:00:18 2012 UTC. The chair is E-P. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 12:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 12:00:28 #topic Current status 12:00:48 o/ 12:01:34 #info Began work to make blts tests more non-root suitable 12:01:58 #info timoph has created rich-core for mer. It can be found from timoph's obs home. It isn't compatible with the maemo/meego version. Documentation still missing. 12:02:42 i'll be also spending some more time on getting tests running in the coming future, as well 12:02:47 so we can get things properly tested 12:03:19 are you executing tests on hw or vm? 12:04:01 a bit of both 12:04:22 good 12:05:02 i've used blts-opengles2 on hw successfully to weed out some bugs as well 12:05:06 which was really nice to have available 12:05:59 so that will probably also be a standard test 12:06:42 we would need more that kind of test assets 12:07:17 yunta: any updates from your side? about test automation? 12:07:55 not really, maybe kontio has something 12:08:19 nope 12:08:39 ah, I raised about 10 qa-related bugs in #nemomobile, some of them may be mer-relevant 12:08:49 yes, some QA work has started in nemo too as well 12:09:08 #info some QA work has started in nemo 12:09:13 s/#nemomobile/nemo bz/ 12:09:25 what is the status of qareports? 12:09:37 i think infrastructure things got a bit pushed forward 12:10:00 as lbt had to flee UK for a week ;) 12:10:24 so we're still waiting to deploy auto-QA 12:10:30 but we also need more test cases, so 12:10:35 o/ 12:10:52 ok, would be nice to have the place where to put test results 12:10:57 yes 12:10:59 easier to share the current status 12:11:19 and see the development of test cases 12:11:58 sorry , too many meetings at the same time 12:12:00 :nod: 12:12:07 phaeron: no problem, welcome 12:12:08 we were discussing qa-reports as well 12:12:21 as a way to share current status and see development of test cases 12:13:10 yeah nothing new , it needs a vm to be deployed , but lbt and I were way too busy to get on it 12:13:19 ok 12:13:26 however with the new imager up , I can get vm_testing + qa reports up in a day 12:13:36 so at least we did *something* :D 12:13:39 sounds good 12:13:44 heh, nice 12:14:55 o/ sry for being late (as usual) 12:16:00 when setting up the qa-reports, we should discuss how to name the targets to the qa-reports 12:16:22 E-P: targets? 12:16:54 meaning, do we put just arm, or armv5l, and for i386 or just intel 12:17:20 tagets should be named similarly as mer architectures 12:17:24 ah, i think we can go with armv6l/armv7l/armv7hl/i486/i586 / mipsel and then what hw adaptation we're on, maybe 12:17:40 https://wiki.merproject.org/wiki/OBS_architecture_naming <- mer port names 12:18:04 well I guess latest / next , arch , 12:18:46 not sure if we need latest/next there as CI/release already points that out 12:19:00 we should have this as a topic for the next meeting? 12:20:09 CI is the per gerrit change 12:20:28 release is when a new release comes out 12:20:41 what else do we have ? 12:21:02 well, per gerrit change, snapshots of post-integration, prereleases, and releases 12:21:06 oh, I though CI/release ment mer version 12:21:22 mer version as in one from http://releases.merproject.org/releases/ 12:22:00 I think Stskeeps wants visibility per change ( or collection of changes at least ) before creating prerelease 12:22:15 ideally we'll be running some degree of test sets on per change 12:22:30 so we'll catch late night stskeeps coding before it makes it into production 12:22:35 Sure 12:22:51 then actual prereleases go to next 12:23:01 :nod: 12:23:27 snapshots of post-integration : I didn't know there was that 12:23:38 that's our 0.0.1 , 0.0.2 stuff 12:23:42 0.1 is a prerelease 12:23:45 .1 is a full release 12:23:51 but I think it is redundant if we do testing during the actual changes 12:23:58 so either or IMHO 12:24:01 yeah, it might be, but still good to check 12:24:05 as sometimes things go wrong 12:24:05 :P 12:24:28 I was orignally thinking only testing for .0.0.x, .0.x and .x 12:24:43 Sage_: it's better to catch in review phase 12:24:48 gives a more dynamic flow 12:24:51 true 12:24:58 and you can assess where the damage actually came from 12:25:13 which brings me to the point how to make submit to tests assets and packages at the same time in gerrit? 12:25:29 as some changes needs more than one package 12:28:22 how that is done currently? 12:28:24 yeah gerrit is suboptimal :D 12:29:10 gerrit's what we use, and there's something called topic branches we might be able to utilize for such a scenario 12:30:02 or simple have a "also-needs:" header our BOSS process can uuse 12:30:04 nothing impossible 12:30:20 * phaeron hides 12:30:33 no hiding, we're in public 12:30:34 :P 12:31:08 we should collect risk items to somewhere 12:31:46 did we have a COBS project for collecting working test cases, btw? 12:32:25 hmm... 12:32:42 or what did we decide in that area 12:32:49 could we have the test run as a voter in gerrit, so it takes the request, builds it, tests it in vm, and gives a vote when ever it passed or not? 12:32:53 I think not, a long time ago we decided the project 12:32:59 kontio: http://review.merproject.org 12:33:03 kontio: check out some sample executions 12:33:12 Stskeeps: just a sec 12:34:21 Stskeeps: I am still using E-P's home project for smoke tests 12:34:25 Stskeeps, Automation Single Build Checker just checks when ever it builds? or does it do a "make check" ? for the unit test? 12:34:34 but a lot are broken 12:34:38 phaeron, Stskeeps: I would suggest that we take the per commit in to account when planning the structure but forget it before we have the others done? 12:35:02 so yes it would be very useful to start promoting working test suites to a higher level project 12:36:33 kontio: ASBC basically runs your package on it's own and checks if it builds on all targets, another on is dependency buildch checker which includes your package and rebuilds everything that's depending on it 12:36:42 kontio: a next step from those repos would naturally be to run image builds and tests 12:37:12 Stskeeps, yeah that is what I meant :-) 12:37:37 for some reason the old meeting minutes don't work 12:37:56 they're now on a new url 12:37:57 sec 12:38:02 but if I remember correctly, the project should be Mer:QA:Tests[:Testing] 12:38:25 ok 12:38:35 * Stskeeps looks in cobs 12:39:21 there is no such project on cobs 12:39:23 it doesn't exist, so please create :) 12:39:28 yeah 12:39:31 i'll create it 12:39:32 ah 12:39:53 I wrote a guideline for those projects, I just have to find them 12:40:22 http://merproject.org/meetings/mer-meeting 12:42:00 i'll ask lbt to create Mer:QA:Tests 12:42:13 and i guess we can go through each testset with guidelines and add them there? 12:42:50 http://merproject.org/meetings/mer-meeting/2012/mer-meeting.2012-05-24-12.00.html 12:42:53 yes 12:43:01 #action Mer:QA:Tests to be created 12:43:09 #action lbt Mer:QA:Tests to be created 12:43:22 done 12:43:27 thanks 12:43:39 https://wiki.merproject.org/wiki/index.php?title=Quality/Development&oldid=2011 12:43:45 when moving to new obs could we start using only lowlever project names? :) 12:43:48 lbt: and me as maintainer too? 12:43:53 yep 12:44:19 I hope we can agree on how to mark test packages as automatic , manual , needs special hardware bla bla 12:44:33 should be possible 12:44:45 otherwise it's be the same mess in that project 12:45:32 phaeron: somewhere else than to test-definition? 12:46:27 i think it was discussed a while back 12:46:45 anyway we agree on is fine 12:47:00 and i didnt come up with anything better than what was suggested, so in 'show me the code' style, the proposal back then becomes the direction.. 12:47:58 should we go to the next topic? 12:48:47 yes 12:48:52 #topic Changes in QA tech lead role 12:49:13 as I wrote to the mailing list, would be better to select a new tech lead 12:49:51 i think we'll go by merit and select when persons show this within the area 12:50:29 would phaeron perhaps be interested in being temporary lead of this area until a new one is found, or him? 12:50:53 I think that phaeron would be a good one, if you are interested 12:51:01 just so we keep the area going forward and somebody who can whip a bit 12:51:14 * phaeron shivers 12:52:04 i think we broke phaeron :) 12:52:25 someone should invent the cloning machine 12:52:26 temporarily ok and if I don't screw up or someone else comes up then I can continue 12:52:32 yep 12:52:36 great! 12:52:47 #info phaeron as temporarily QA lead 12:53:35 I will be hanging on the channel, so you can always ask me 12:53:53 E-P: thanks 12:54:47 good, anything else for today? 12:56:07 no from me :D 12:56:18 ok, thanks for all 12:56:22 thank you E-P for your service 12:56:27 and contributions :) 12:56:29 it was my pleasure 12:56:31 thanks E-P for getting us here 12:56:39 E-P, don't leave us totally, please :) 12:56:59 iekku: I won't :) but I am going to be hell busy next weeks/months 12:57:11 we need clones! 12:57:40 #endmeeting