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