10:00:33 <timoph> #startmeeting Mer platform SDK status meeting
10:00:33 <MerBot> Meeting started Fri Mar 16 10:00:33 2012 UTC.  The chair is timoph. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
10:00:33 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
10:00:56 <lbt> morning
10:00:57 <timoph> minutes from the last meeting here -> http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.html
10:01:10 <timoph> we had one action for lbt
10:01:38 <timoph> "setup bug/tasks for the alternative SDK versions to help track them"
10:01:50 <timoph> lbt: any news on that?
10:02:10 <vgrade> morning , I see we have some plasma active guys here today, apol, notmart, djszapi, chouchoune
10:02:22 <lbt> no, I didn't realise it was mine particularly :)
10:02:26 * notmart is here :D
10:02:43 <lbt> I thought I just raised it :)
10:02:48 <timoph> lbt: oh. actually it wasn't pointed to anyone :)
10:02:54 <timoph> so not done I quess :)
10:03:07 <timoph> lbt: want to take it now?
10:03:10 <Stskeeps> i don't fully understand that action, can it be elaborated?
10:03:10 <lbt> I can do it though
10:03:20 <chouchoune> vgrade: I'm not
10:03:46 <chouchoune> and hi all
10:03:48 <lbt> Stskeeps: yeah, there's activity on a VM SDK by phaeron and I'm looking at lxc as a "better chroot"
10:04:02 <lbt> we also want something to drop into Qt creatore
10:04:27 <lbt> finally there's a template-y thing to allow vendors to make a modified SDK
10:04:34 <timoph> so it's about configurations
10:04:43 <lbt> say one with eclipse or something Jenkins-y in it
10:05:15 <lbt> yes, I think that's a key part timoph
10:05:29 <lbt> I feel it blocks on kickstarter capabilities too
10:05:46 <lbt> I mainly don't want our SDK to get too stovepiped
10:06:43 <timoph> #action lbt to setup bug/tasks for the alternative SDK versions/configurations to help track them
10:06:49 <lbt> :)
10:06:55 <timoph> :)
10:07:15 <timoph> #topic current status
10:07:50 <timoph> nothing to update from me. <excuses here>
10:08:54 <Stskeeps> #info been experimenting with QA tools inside SDK: http://releases.merproject.org/~carsten/testtrunner-manual.png , http://releases.merproject.org/~carsten/qa-testrunner.png , http://releases.merproject.org/~carsten/hostbased.png , http://releases.merproject.org/~carsten/testplanner.png
10:09:21 <timoph> any problems?
10:09:48 <Stskeeps> so far nothing a lot, except needing to add fonts and possibly icon sets
10:10:24 <Stskeeps> so we might want a package group for QA tools
10:10:48 <timoph> on a related note. one of the original testrunner-lite developers (sampos) promised to contribute to it if needed
10:11:28 <timoph> so we have someone who really understands how it works if there problems with it
10:12:42 <timoph> lbt: anything from you?
10:12:53 <lbt> yes
10:13:02 <lbt> just looking at where we were - since last meeting we got a clean /cross repo which I'm using in SDK images now.
10:13:23 <lbt> This is now part of the release process and will work as we develop more ports
10:13:38 <lbt> I also updated osc and build to have sb2 support which will be in this weeks release
10:13:43 <Stskeeps> (so cross compilers are available)
10:14:00 <lbt> yes, 'properly' :)
10:14:27 <timoph> do we provide them with the image or does one need to install them?
10:14:32 <lbt> I have some work in progress on the sb2 package modes to allow zypper to work
10:14:37 <lbt> it's not hard
10:14:47 <lbt> I'm also writing docs as I go
10:15:07 <lbt> oh, timoph, I re-arranged the wiki pages a bit - hope that's OK
10:15:21 <timoph> zypper without emulation? worked with sb2 -e for me earlier
10:15:26 <lbt> I tried to keep the initial page a very simple "get it going"
10:15:35 <timoph> np
10:15:38 <Stskeeps> timoph: yeah, lbt takes the other approach, fast tools
10:15:39 <lbt> timoph: no, proper acceleration
10:15:48 <timoph> good
10:16:17 <lbt> I'm also looking at best practice on setting up targets
10:17:05 <Stskeeps> since we have test planner now, we should set up some sanity tests
10:17:11 <Stskeeps> perhaps automate some of them
10:17:43 <Stskeeps> so we don't stray from basic use cases going broken
10:17:49 <timoph> yep
10:18:04 <lbt> can we start by having manual ones?
10:18:11 <Stskeeps> that's fine too
10:18:29 <Stskeeps> just to write them up in a format that integrates with our test tools
10:18:31 <Stskeeps> http://releases.merproject.org/~carsten/testplanner.png
10:18:31 <lbt> good - I fear being sucked into VM deployment madness otherwise
10:19:15 <lbt> who can take an action to write up some basic tests
10:19:35 <lbt> eg "build an image", "osc ls", "sb2 gcc helloworld.c"
10:19:46 <timoph> I can
10:19:58 <lbt> which is essentially what page 1 of the install should be saying
10:20:04 <timoph> I need to do that anyway since I'm going to work on the configuration package
10:20:05 <lbt> timoph: ta
10:20:32 <timoph> test automation configuration package (eat) that is
10:21:33 <timoph> #action timoph to write some basic tests using s/MeeGo/Mer/ QA tools
10:21:35 <timoph> :)
10:23:13 <lbt> great - I'll use them as soon as you have them
10:23:41 <timoph> #info current status is that we have QA tools working in the SDK, saner cross compilers and work on going to enable sb2 zypper without emulation
10:23:54 <timoph> did I miss something?
10:24:07 <Stskeeps> sounds good
10:24:19 <lbt> another release is pending
10:24:23 <timoph> #topic next steps
10:24:29 <lbt> another release is pending
10:24:30 <lbt> :)
10:24:36 <lbt> with fixes to known bugs
10:24:37 <timoph> :)
10:25:03 <lbt> for most cases zypper ref; zypper up should work
10:25:10 <Stskeeps> speaking of releases -- if we get sane test sets going, who here would volunteer to help run them on SDK pre-releases?
10:25:12 <lbt> if it doesn't then please report
10:25:25 <Stskeeps> mostly just walk through test cases, mark pass/failed, possibly file bugs
10:25:46 <vgrade> \o
10:27:17 <lbt> I will do a tutorial too
10:27:56 <timoph> so we're making a sanity/regression test set for the sdk
10:27:59 <lbt> essentially how to run gcc on a simple Mer sb2 target
10:28:04 <lbt> timoph: yes
10:29:15 <timoph> ok. so I need to do that AP asap
10:30:11 <lbt> I'm thinking about having it as an element of the SDK install
10:30:19 <lbt> kinda like a validation step
10:30:27 <timoph> #info making a sanity/regression test set
10:30:57 <lbt> so ideally you'd run some t-r script and your SDK would say "I'm fine"
10:31:18 <lbt> self-diagnosing SDKs ... \o/
10:31:35 <timoph> in that case we need at least two versions for the set. light/fast one and the full thing that can be run nightly or so
10:32:05 <lbt> OK - and lite/fast is a good start too
10:32:25 <Stskeeps> right, first manual testing though
10:32:33 <Stskeeps> good way to involve people in mer QA, too
10:32:36 <lbt> yes - that's what I meant
10:32:48 <timoph> we just need to write down the manual tests
10:33:05 <timoph> as in define them :)
10:33:17 <lbt> so the AP could supplement the install wiki page
10:33:32 <lbt> s/AP/testplan/
10:34:12 <timoph> yeah. need add things to the QA section. currently is only says "TBD"
10:35:28 <lbt> *nod*
10:36:29 <timoph> so QA is one major theme in going forward. Any new features that we need to start pushing forward?
10:36:41 <Stskeeps> any feedback from the PA people who started looking into SDKs too?
10:36:57 <timoph> or do we declare this as a QA sprint?
10:37:39 <Stskeeps> i think a bit of both, we need to make sure our SB2 and build-your-own-sb2 target works
10:37:55 <Stskeeps> and nothing says this than a nice bunch of test cases to prove it to the world
10:37:58 <Stskeeps> :P
10:38:03 <timoph> :)
10:39:38 <timoph> so I'm going to forget the qtcreator stuff for now and focus on the QA side of things for the time being
10:39:59 <Stskeeps> qtcreator needs a little more 'oomph' to work properly as well
10:40:06 <lbt> I agree
10:40:06 <Stskeeps> ie, multiple sysroots, etc
10:40:12 <timoph> yep
10:41:36 <vgrade> kdevelop and madde were mentioned at the PA sprint as being used is current workflows
10:42:18 <Stskeeps> i need to look closer at MADDE, nothing scares me more than running perl on windows..
10:42:58 <vgrade> the guys would be able to tell more if they were here I guess
10:43:06 <Stskeeps> they're welcome next week too
10:43:14 <djszapi> I am here.
10:43:49 <djszapi> my opinion is that it is a personal taste how you build software, either madde, or a full environment, and I think we got in our community both types of people, so we probably need support for both.
10:44:33 <Stskeeps> no doubt, hence the sb2 strategy
10:46:00 <Stskeeps> so i think we need basic platform development story going first
10:46:08 <notmart> at the sprint basically in the end the opinions were split in 2: a full environment either chroot or vm, wins on getting a build environment run fast, something like madde wins for potential ide integration but more a pain to setup
10:47:16 <Stskeeps> on the VM side, we've just integrated llvmpipe so we should be able to do 'sane' vm images soon
10:47:25 <Stskeeps> for testing sw
10:47:42 <Stskeeps> full environment is what we're working on with platform sdk
10:48:15 <notmart> personally, talking with more "causal" developers (maybe aseigo could tell a bit more since he did some interviews at cebit just to taste waters in this sense) i am under the impression that something that is as fast as possible to setup and get running and that touches the host machine as less as possible is what many people want
10:48:22 <djszapi> basically it is probably not simpler in my opinion to integrate MADDE into IDEs, but the thing is that QtCreator already achieved a lot in that sense, so probably simpler to establish this support in KDevelop. Some people prefer MADDE as well because they do not have a "full-blown" environment, just what they need, but imo this topic is all about personal tastes, so I do not see any reasons to just support one or other.
10:48:42 <notmart> looking forward to those vm images tough ;)
10:49:23 <Stskeeps> notmart: yep, i think platform sdk is 'touches as litle as possible' as we're essentially a chroot
10:49:30 <Stskeeps> with no extra tools needed than that
10:49:37 <lbt> notmart: I can see the madde execution happening inside an SDK
10:49:54 <Stskeeps> lbt: i can't, for silly reasons like windows..
10:50:03 <Stskeeps> notmart: some might disagree on root usage, but..
10:50:33 * lbt has this nice habit of forgetting that Windows exists
10:50:36 <djszapi> does sb2 work on Windows ? (scratchbox did not).
10:50:39 <notmart> lbt: yep totally, and in this case would be already setted up and working, that makes quite a difference as developer story ;)
10:51:03 <Stskeeps> djszapi: no, on windows only alternative would be a linux VM, or MADDE
10:51:50 <djszapi> how about Mac ?
10:52:11 <Stskeeps> same situation there, i believe
10:52:18 <Stskeeps> i don't know how mac and madde looks like
10:53:03 <djszapi> which distributions do you support on Linux initially ?
10:53:04 <lbt> I can't see why the GUI sdks can't invoke commands into a 'screen'
10:53:14 <Stskeeps> djszapi: we're a chroot, so anything that can run the 'chroot' command
10:53:16 <lbt> even via ~ssh on windows
10:53:35 <djszapi> are we able to create custom images on other distributions ?
10:53:41 <Stskeeps> djszapi: yes, within the SDK
10:53:53 <djszapi> ok, it sounds better than raspberry :)
10:53:57 <djszapi> good.
10:54:14 <Stskeeps> we are not willing to take on the burden of supporting all our tools on all distros out there, so we chickened out and went for chroot approach
10:54:19 <Stskeeps> as we then know tools -work-
10:54:28 <timoph> yeah
10:55:05 <timoph> (had to take a call - reading backlog)
10:56:25 <timoph> the PA thinking sounds pretty similar to what we've been talking. full chroot for platform dev and madde/vm for app dev
10:56:44 <timoph> if I understood correctly..
10:57:33 <Stskeeps> :nod:
10:57:42 <Stskeeps> so, 3 minutes left of our time slot, anything else before wrapup?
10:57:43 <djszapi> yeah, about.
10:58:35 <lbt> I'm good - I made some notes about how usage is expected to develop
10:59:02 <vgrade> thanks to the PA guys for attending
10:59:08 <lbt> I think we're looking for more feedback on realworld use too
10:59:39 <lbt> so confirmation that it's being used as an everyday tool would be good
10:59:50 <timoph> #info feedback and input welcome
11:00:07 <vgrade> lbt, http://wiki.merproject.com/wiki/Community_Workspace/RaspberryPi worked for me
11:00:54 <lbt> vgrade: great
11:00:57 <timoph> ok. that's it for this week. thank you for attending
11:01:02 <lbt> thanks all
11:01:06 <djszapi> thanks to everybody :)
11:01:17 <timoph> #endmeeting