09:00:57 <timoph> #startmeeting Platform SDK status & brainstorming
09:00:58 <Merbot> Meeting started Tue Sep 18 09:00:57 2012 UTC.  The chair is timoph. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:00:58 <Merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:01:13 <timoph> who do we have here?
09:01:17 <Stskeeps> o/
09:01:19 <lbt> o/
09:02:14 <timoph> ok. maybe others will join later
09:02:26 <timoph> #topic current status
09:02:40 <timoph> lbt go ahead :)
09:02:44 <lbt> So, current status of SDK is that there was a release yesterday http://www.mail-archive.com/mer-general@lists.merproject.org/msg00761.html
09:02:52 <lbt> That's version 6.1.0
09:02:58 <lbt> The docs at https://wiki.merproject.org/wiki/Platform_SDK are reasonably up to date
09:03:19 <lbt> My plans are to improve the contribution mechanism and to work on integration with QtCreator (more about this later)
09:03:49 <lbt> I want Mer core to move to gitpkg mechanism and I'm starting by mandating that for Mer:Tools
09:04:19 <lbt> I'd like to use http://gitweb.merproject.org/gitweb/ for git but there are issues with it atm
09:04:23 <timoph> #info latest sdk release http://www.mail-archive.com/mer-general@lists.merproject.org/msg00761.html
09:04:44 <timoph> #info wiki reasonably up to date
09:05:20 <lbt> I'm going to use https://github.com/mer-tools unless there are other suggestions
09:05:25 <timoph> so contributions would follow the regular mer contribution model?
09:05:45 <lbt> no
09:06:18 <lbt> mer core is very much a packaging model and has the unhappy "tarball in git" thing
09:06:24 <Stskeeps> lbt: i'd like to see a proper attempt at making this work with gerrit, or at least a list of reasons why it won't
09:06:45 <lbt> Stskeeps: for sure - my main concern is gerrit doesn't handle merges - only single commits
09:07:10 <lbt> I will look at this though
09:07:50 <lbt> so some of our tools are simple packaging of upstream - others are natively developed
09:07:52 <Stskeeps> k, because i'm not fond of a very essential part of mer work being external/different to rest of processes
09:08:06 <Stskeeps> also, how does github deal with merges that have to come in together? (packaging branch, main branch)?
09:08:36 <lbt> good question
09:08:45 <Stskeeps> because that's a comparable issue as to gerrit issues
09:08:54 <Stskeeps> anyway, we can take that discussion offline
09:09:01 <lbt> until this point I've been mainly handling Tools on my own so not needed to resolve it
09:09:15 <Stskeeps> right, though you don't scale
09:09:28 <Stskeeps> (unless we get that coveted cloning equipment)
09:09:28 <lbt> yeah
09:09:40 <timoph> yep. you've done great job but imo we need to enable contributions from others as well
09:09:57 <lbt> I have thought that gerrit may work if we only focus on pkg-mer branch
09:10:19 <lbt> but anyhow this is now a discussion of contribution issue solutions
09:10:35 <Stskeeps> right, just letting you know my views
09:11:11 <Stskeeps> do we have criteria for Mer:Tools vs Mer:Tools:Testing yet btw?
09:11:21 <lbt> not really
09:11:27 <Stskeeps> ok
09:11:30 <lbt> we have very few test assets
09:12:04 <timoph> that's what you get having bunch of tools developers around and not so many test devs :)
09:12:21 <lbt> I think it's as simple as build in Mer:Tools:Testing - limited testing, if it builds/installs, promote to M:T
09:12:32 <Stskeeps> does performance measurement tools belong in Mer:Tools ?
09:12:33 <lbt> then M:T is used to make releases
09:12:42 <lbt> I think so
09:13:12 <lbt> I consider it things you need to help you develop solutions that doesn't go in Core
09:13:25 <Stskeeps> alright
09:13:31 <lbt> I'm not sure about emacs - but it's in there :)
09:13:43 <timoph> someone will miss it if it's not there
09:14:23 <lbt> so reasonably broad scope
09:14:35 <Stskeeps> k
09:14:37 <timoph> yep.
09:14:51 <lbt> I think it *may* be worth moving ruby/python/perl modules out at some point
09:15:14 <lbt> but then we have to sync releases etc etc
09:15:35 <timoph> #topic brainstorming - where to go from here?
09:15:54 <lbt> well, we can have a topic for qtcreator
09:15:59 * timoph trying to get some minutes out of this
09:16:39 <timoph> you had something to share regarding it?
09:16:51 <lbt> #topic QtCreator and MADDE
09:17:00 <timoph> #undo
09:17:00 <Merbot> Removing item from minutes: <MeetBot.items.Topic object at 0x8d4344c>
09:17:07 <timoph> #chair lbt
09:17:07 <Merbot> Current chairs: lbt timoph
09:17:12 <lbt> ah :)
09:17:16 <lbt> #topic QtCreator and MADDE
09:17:45 <lbt> so I've had some discussions with people about working with QtCreator on various non-linux platforms
09:17:50 <lbt> also on linux
09:18:13 <lbt> the solution we came up with was to run a VM with SDK and sb2 inside it
09:18:36 <lbt> probably virtualbox due to support on many non-linux platforms
09:19:22 <lbt> this VM would run in a headless/minimised mode and would have a private VLAN connection to the host (as is normal)
09:19:41 <timoph> so we could ship virtual box images with the sdk already setup for Qt Creator use?
09:19:42 <lbt> it would likely run sshd there and would share the host fs
09:19:44 <lbt> yes
09:20:11 <lbt> then QtCreator would have a set of build commands which would invoke ssh driven commands into the VM
09:20:25 <lbt> this would run SB2 builds as normal
09:20:34 <Stskeeps> http://doc.qt.nokia.com/qtcreator-2.5/creator-remote-compiler.html
09:20:39 <Stskeeps> might be interesting in that aspect
09:20:48 <lbt> Stskeeps: yes, that's on the list to investigate
09:20:55 <lbt> ty fot the link :)
09:21:22 <lbt> so that falls into 2 threads of work: VM and QtCreator extensions
09:21:42 <lbt> I'm handling the VM/SDK side and alterego is doing the QtCreator plugins
09:22:29 <lbt> overall this means we don't need to support MADDE, all tools use the same SDK/toolchain on all platforms (linux/windows/osx...)
09:23:04 <lbt> also we have very limited need to support non-linux ourselves - all platform specific code is in vbox
09:23:35 <lbt> I'm expecting a proof of concept in the next week
09:23:57 <lbt> thoughts/questions ?
09:24:27 <timoph> not really. easier to comment after I get my hands on it
09:24:45 <lbt> ok - so that's the update there.
09:24:46 <timoph> but sounds like it should do the job
09:25:21 <timoph> ok. now for the brainstorming bit
09:25:33 <lbt> yep
09:25:43 <timoph> #topic Brainstorming - where to go from here?
09:26:08 <lbt> we're using versioned releases at the moment
09:26:27 <timoph> do we have a symlink to the latest?
09:26:30 <lbt> I would like to have a repo that I rewrite on a regular basis
09:26:44 <lbt> http://repo.pub.meego.com/releases/Mer-Tools/
09:27:49 <lbt> so I wondered about making one called 'rolling'  and re-publishing to it each time I promote to M:T (or correct a pattern or....)
09:28:14 <lbt> it would be for SDK developers, not users (but you know.. nothing stopping them)
09:28:38 <timoph> hmmh. sort of an experimental "branch"?
09:29:15 <lbt> yeah - but it uses the full release process - so it exercises the release scripts and grouping mechanisms too
09:29:34 <lbt> experimental is too ... scary
09:29:52 <timoph> btw, how far are we from having releases in sync with mer releases
09:30:07 <lbt> when I automate this stuff
09:30:36 <lbt> also our releases are not trivially reproducable
09:30:41 <lbt> we don't use MDS
09:31:03 <lbt> once gitpkg is up properly that may change
09:31:12 <timoph> k
09:31:52 <lbt> OK - I'll be quiet for a bit - anyone else?
09:32:09 * timoph reading the comments on the mailing list thread
09:32:57 <timoph> the application issue should be one step closer to being resolved after the vm thing is out
09:33:09 <timoph> (one topic raised in the mails)
09:34:14 <timoph> anyway, one of the things I'd like to see improved is the mounting/entering/umounting mechanism
09:34:30 <lbt> o/
09:34:45 <timoph> currently it leave a bit too much room for user mistakes
09:35:32 <lbt> phdeswer: I don't have the url for the logs to hand
09:35:36 <timoph> imo we need some smart script to handle entering the sdk
09:35:50 <lbt> timoph: meh
09:35:58 <phdeswer> lbt, that's ok. We will figure things out later
09:36:10 <lbt> it's /srv/mer/sdks/sdk/mer-sdk-chroot enter
09:36:19 <lbt> it doesn't get much easier :)
09:36:24 <timoph> http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-09-18-09.00.log.txt
09:36:44 <timoph> I know your opinion on this :)
09:36:45 <lbt> we could go for the whole sb2-init .... sdk --target=<name> --action=enter ?
09:37:00 <lbt> but seriously... it's just lack of familiarity
09:37:05 <timoph> true
09:37:17 <lbt> "mount, then enter"
09:37:28 <lbt> I'm happy to try to automate the mount - it's not that hard
09:37:36 <lbt> but if it fails we should bounce them
09:37:47 <lbt> the umount is not so good an idea
09:38:05 <timoph> but having a script that mounts when you first enter and umount when last window exits shouldn't be impossible
09:38:33 <timoph> some people power off their machines for the night :)
09:38:46 <lbt> no - but will you personally guarantee it works if the machine crashes and reboots?
09:38:56 <timoph> no :)
09:39:00 <lbt> me neither
09:39:13 <lbt> so if we don't have resource to QA it we shouldn't do it
09:39:34 <timoph> hmmh
09:39:44 <lbt> I'll take patches from people who can commit to support recovery if it goes bad :)
09:40:04 <lbt> note - we had one guy rm -rf his /home already...
09:40:09 <timoph> one more reason to have a review system in place for the sdk as well
09:40:58 <lbt> so, this is my reasoning - I'm happy to debate it and to discuss patches
09:41:02 <timoph> there's no fix to stop people from doing that
09:41:33 <timoph> I'll see if I can come up with something
09:41:52 <timoph> mainly because I'd like to use something like that
09:42:17 <lbt> sure - the mount-on-enter side is relatively safe and I almost implemented it myself
09:42:34 <timoph> yeah. the umount bit needs thinking
09:42:37 <lbt> the main thing is it should detect any error during mount and not enter
09:42:53 <lbt> any other issues?
09:42:55 <lbt> Docs is one
09:42:59 <timoph> yep
09:43:26 <timoph> there was a request to have general instruction for setting up sb2 targets
09:44:17 <lbt> I think we have an overall docs issue anyhow
09:44:22 <timoph> true
09:45:15 <timoph> well. only way to fix that is to edit the wiki :p
09:45:18 <lbt> on 3 (4?) levels: access to reference material; Mer-specific processes; Mer best practice; maybe policy
09:45:35 <lbt> some docs come from code and should autogen on release
09:45:43 <timoph> yep
09:45:49 <lbt> http://autodoc.meego.com/
09:46:27 <lbt> something like that with per-release manpages, api/doxygen etc
09:46:51 <timoph> at least I'd like to see something like that
09:46:54 <lbt> our processes are kinda OK for core
09:47:08 <lbt> not even understood for Mer:Tools
09:47:43 <phdeswer> ^^^^ indeed
09:48:04 <lbt> 'best practice' is things like setting up sb2 targets; when to branch an OBS project, when to fork git...
09:48:19 <lbt> phdeswer: some stuff in backlog too
09:48:34 <timoph> yeah. I think we can solve most of the problems people are having just by improving the docs
09:48:45 <lbt> policy ... well.... hmm
09:48:58 <timoph> not that important
09:49:05 <lbt> mmm
09:49:16 <timoph> at least rightaway
09:49:41 <lbt> well, when people get work rejected due to not using spectacle or ...
09:49:55 <lbt> or failing unwritten QA rules
09:50:02 <lbt> it's discouraging
09:50:24 <timoph> well, there's that but I'd start from documenting the usage & best practises bits anyway
09:50:30 <lbt> yep
09:50:54 <lbt> any other docs areas anyone ?
09:52:35 <timoph> how about some sort of info for vendors on how they could abuse the sdk
09:52:59 <timoph> although that should be covered already by the rest of the docs
09:53:02 <lbt> yeah - that could go  alongside Mer:Tools stuff
09:53:19 <timoph> yep. mainly about adding and enabling stuff
09:53:24 <lbt> since  SDK = Mer Core + Mer:Tools
09:53:38 <lbt> we could do with info on the SDK release process
09:54:07 <timoph> anything we want to hilight on the minutes?
09:56:30 <timoph> #info wish: autogenerated reference docs with releases
09:57:15 <timoph> #info wish: showing wiki some love. processes, best practices, examples, policy, ...
09:57:54 <lbt> hnnnnnnnnnnnnnnnnnnnnn
09:58:01 <timoph> ?
09:58:03 <lbt> sry kitten
09:58:05 <timoph> :D
09:59:31 <timoph> #info no consensus about sdk enter script. needs thinking and prototyping, and to convince lbt :p
09:59:40 <lbt> not many voices in the discussion - any other comments? complaints?
10:02:17 <timoph> evidently it's working for most of the people
10:02:17 <timoph> if nothing else. I think we're done
10:02:17 <timoph> thanks
10:02:17 <lbt> ah
10:02:17 <lbt> one other thing
10:02:17 <lbt> we're looking at the SSU mechanism used in maemo
10:02:17 <lbt> and possibly trying to put something like that into SDK
10:02:18 <lbt> just FYI
10:02:18 <timoph> anything more you can share about that now?
10:02:52 <timoph> we can chat about that later
10:03:11 <timoph> we're in overtime already
10:03:18 <timoph> #endmeeting