12:00:51 #startmeeting Mer QA meeting 21/05/2012 12:00:52 Meeting started Thu Jun 21 12:00:51 2012 UTC. The chair is E-P. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 12:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic. 12:01:15 Agenda for the meeting is http://www.mail-archive.com/mer-general@lists.merproject.org/msg00560.html 12:01:27 #topic Current status 12:01:50 o/ 12:01:58 I have been away the last two weeks, so I don't have anything 12:02:10 lbt, Stskeeps: anything from the Summit? 12:02:48 Nothing specific from the summit 12:02:51 #info illustrated doing a tsestable image in 30 mins and booting it on raspberry pi 12:02:54 #info in 30 mins 12:03:00 #info worked perfectly 12:03:11 #info testrunner-ui needs to go onto mer:tools 12:03:11 #info used eat, testrunner 12:03:31 Stskeeps: great, do you have video or documentation about that? 12:05:37 lbt: do you have anything? 12:05:49 #info OBS copyproject verified working (important for the automated image creation) 12:05:55 thanks to phaeron 12:05:57 hello 12:06:28 I think we now have a slight blocker there with the 'change source link' 12:06:34 phaeron: welcome, http://mer.bfst.de/logs/%23mer-meeting/%23mer-meeting.2012-06-21.log 12:06:45 E-P: video will come 12:07:14 ok 12:07:16 err 12:07:18 Stskeeps: nod 12:07:37 E-P: i also found out how to bring up eth0 on boot 12:07:48 phaeron, lbt: good progress 12:08:01 Stskeeps: with connman? 12:08:18 no, kernel command line 12:08:24 so we can adjust it in .ks 12:09:16 Stskeeps: do you know if connman may effect to the connection when using your method? 12:12:00 #info kernel command line can be used for bringing up eth0 on boot, and this can be done in .ks file 12:12:13 E-P: shouldnt mattetr much i think 12:12:41 anything else? 12:12:45 so good progress, at least 12:12:58 definitely :) 12:13:33 #info OBS upstream is using travis-ci.org to do CI on their github tree for master branch; This could be useful for MerOBS too. 12:14:22 lbt: do you know what kind of CI they have? compiling + testing? 12:14:53 not looked in detail - this would help us explore it 12:15:12 the service is described as not useful for internal, closed projects 12:15:22 nod 12:15:29 which means it may not be right for our vendors 12:16:12 I think I'll log a task bug to look at that 12:16:20 thanks 12:18:19 ok, let's move on 12:18:24 #topic Acceptance criteria for the tools and tests 12:18:50 lbt, you raised this issues couple of meetings ago 12:19:10 I listed some ideas to the meeting invitation 12:20:09 OK 12:20:28 we can start with the tools 12:22:17 we can use similar process for tools that we are using for core packages, code review + testing 12:22:32 yes, I was thinking about this 12:23:04 The problem is that the gerrit system runs on merproject.org and cobs/Tools:* is on meego.com 12:23:28 not sure it matters too much - may have to link the BOSS systems 12:23:51 or find a way to rlease it within mer ci.. 12:24:01 *nod* 12:24:47 I'm not unhappy about having a discrete cobs though - feels right 12:25:05 I am a little concerned that core gets far fewwer commits than some of the tools 12:25:51 and that the per-commit nature of gerrit may be a problem - cf the SR nature of OBS which is more of a "done lots of work, lets push to integration" 12:27:01 keeping in mind providing a cookie-cutter version of this process for vendors is one goal (eventually) 12:27:59 how the tools development is done currently? do you use some external version control before submitting to gerrit? 12:28:00 so for now I wonder about doing SRs 12:28:15 yes - all VC is git somewhere 12:29:19 using the SRs also for the code review? 12:29:56 I think so - possibly asking for a github diff URL or something? 12:30:37 might work 12:31:41 shall we investigate an SR approach then? 12:31:59 we could try that out and see how it works 12:32:05 means we're not dependent on externals 12:32:28 just need to do something similar to the http://wiki.merproject.org/wiki/Contribution_in_detail page for Tools 12:32:59 we can add the info to the http://wiki.merproject.org/wiki/Quality/Development 12:33:21 yes 12:33:26 step 1: consult the package DB to find where the right git repo is ... d'oh, no package DB !! 12:34:03 E-P: also ... don't forget we have http://wiki.merproject.org/wiki/Category:About 12:34:24 lbt: that is new to me :) 12:34:40 OK - see the guidelines page too 12:34:49 QA should be in there 12:34:51 I have to add some stuff into that 12:35:12 each tool probably has an About: category too 12:37:11 I will file a task about those, upding the wiki and creating pages/links for QA 12:38:06 in the tool's wiki page there should be an url to the right git repo 12:39:01 yes, that's usually a good way to point people in the right direction 12:41:15 after the changes are done to the tool, SR is made with url to the diff 12:41:25 yes 12:41:27 and SR is made to Mer:Tools:Testing 12:41:46 hmm 12:42:04 M:T:T is a kinda team area 12:42:33 I think there are 2 class of contribution 12:42:35 git pull 12:42:37 and SR 12:43:10 git pull is done on the git repo and the team handle it and push to M:T:T 12:43:16 freely 12:43:23 then the team impose rules on themselves 12:43:30 and SR from MTT to MT 12:43:41 hmm 12:44:25 yeah 12:45:11 the problem is that we don't have enough automated testing 12:45:12 so if someone wants to make a change, he/she makes the change to the VC and the tools team will push it to the M:T:T? 12:45:24 yes 12:45:48 we're not doing CI on tools 12:46:00 at least, not in the release sense 12:46:21 we may do some minor continuous build testing 12:46:53 definitely, some of the tools have kind good unit tests (testrunner, OTS, min) 12:47:05 yep 12:47:25 but, for example, do we verify a change to mic doesn't cause problems in the SDK and the IMG server 12:48:25 we should, mic is one of the most important tools 12:48:43 at least some minor testing if possible 12:48:58 yes 12:49:36 and I think that's why I want an SR and a review between MTT and MT 12:50:09 also don't forget that MT is the 'trunk' branch - ideally it should be ready for a release 12:50:53 so we may stop taking SRs for a bit and then we do some broader tests, if all is good we do a numbered release 12:51:12 then build things like SDK 12:51:24 sounds reasonable 12:51:57 phaeron: any comments on this - I know how much pain MINT was back in the day 12:53:16 yeah well having the appliance was kind of a continuous test 12:53:33 btw, we will have also the Project:MINT project for server tools 12:53:49 I might be working soon on generic vm based testing 12:53:55 so will report back how it goes 12:54:49 sounds good 12:55:03 will try to make it as close as possible to eat and testrunner 12:55:09 hoping they are flexible enough 12:55:29 phaeron: Stskeeps had solution for setting up the eth0 12:55:44 yes I know, that's at least a first step :) 12:55:47 great 12:56:23 using similar process for the Project:MINT as to the Mer:Tools? 12:56:53 yes if I can make this work , it should be applicable to anything as long as the testcases are available 12:57:22 ok 12:57:32 then to the tests 12:58:19 I would say that we only accept tests that are passing 12:59:17 we had some issues with failing tests in the pass, some of them never got passed due to some reason 12:59:45 yep 13:00:00 and if a test depends on a bug being fixed - so be it 13:01:04 yep 13:01:35 otherwise the similar process for the tests too 13:01:45 code review, integration and testing 13:02:12 one problem is that on which HW we should execute the tests? 13:02:25 yup 13:02:38 this is back to the discussion on test metadata 13:02:54 yes 13:03:33 so lets treat VMs as just another platform 13:03:40 nothing special about them 13:03:56 for now we can accept the test if it passes on one platform (vm or real) 13:04:09 well 13:04:11 yes 13:04:22 ideally we'll have feedback and permit veto 13:04:38 and if it *fails* on any platform, we reject 13:05:15 (or manipulate the metadata to handle a known exception) 13:05:26 yes 13:07:43 do we have a "team" for tools and for tests? 13:08:03 anyone with maintainer rights in the project 13:08:16 ok 13:09:12 #info gerrit might cause some problems due to per-commit nature 13:09:18 #info code review, integration and testing are required for tools 13:09:22 #info each tool must have a wiki page with url to the right version control 13:09:25 #info using submit requests for tools with link to the changes diff 13:09:32 #info submit requests are done from Mer:Tools:Testing to Mer:Tools 13:09:37 #info Tools team updates the tools to Mer:Tools:Testing 13:09:48 #info Mer:Tools:Testing is used for wider testing before SR are accepted 13:09:56 #info Mer:Tools is always ready for release 13:10:04 #info using the same process for Project:MINT tools 13:10:24 #info only accepting tests that are passing, failing tests are rejected 13:10:37 #info otherwise using the same process for tests that for the tools 13:10:48 #info the test should pass on all devices, for now we can use virtual machine 13:11:00 something to add? 13:11:21 #info Packages that are shared between MINT and Tools should be 'mastered' in Tools 13:12:11 good info 13:13:34 if nothing else, we are done 13:14:01 thanks for everyone, I will update the wiki 13:14:30 #endmeeting