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