11:07:40 <lbt> #startmeeting Mer Release Mangagement meeting 22 May 2012
11:07:40 <MerBot> Meeting started Tue May 22 11:07:40 2012 UTC.  The chair is lbt. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
11:07:40 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:07:59 <lbt> Afternoon all
11:08:07 <Stskeeps> mangagement? oh dear :)
11:08:09 <Stskeeps> ;)
11:08:35 <lbt> you've seen my sig... I'm all about the cartoons ... and Manga is fine by me !
11:08:38 <Sage> o/
11:09:09 <Sage> Stskeeps: Monday continues? ;)
11:10:04 <Stskeeps> #info Mer release coming along quite nicely, zlib, connman, bluez, gstreamer, some NEON optimizations for libpng, some CVE fixes
11:10:15 <Stskeeps> #info qtdeclarative and rest of qt5 coming during tomorrow
11:11:19 <lbt> *nod* we're post-Tizen conf, Releases are "business as usual", we have work proceeding on systems and tools; QA is getting started ... anything else? Thoughts?
11:12:02 <Stskeeps> #info First next-generation SB2 build in OBS completed today, http://releases.merproject.org/~carsten/sb2-b1-obs-victory.txt
11:12:46 <Sage> note, connman has probably API break so vendors might get regressions.
11:12:53 <Stskeeps> info that please
11:13:13 <Sage> #info connman update to 1.0 has API break, so vendors might see regressions.
11:13:22 <lbt> and we should make a big note in the snapshot mail too
11:13:37 <Sage> #info connman 1.0 version should be API stable so that is a good thing.
11:13:57 <Sage> also ofono update is pending I have it packaged already but has also api break
11:14:04 <lbt> nb - I do those notes from changes entries
11:14:07 <Sage> haven't submitted to review yet though
11:15:51 <Sage> Btw, because of this api brake I would suggest we extend this release testing perious 1 week.
11:16:29 <Sage> 2 weeks is not long time for testing especially than the first testing release isn't out yet. so it is more like 1 week of testing
11:16:50 <Stskeeps> OK with me
11:16:51 <lbt> I tend to agree
11:17:00 <Stskeeps> until we have QA up and running..
11:17:08 <Stskeeps> (which isn't QA's fault that it's not..)
11:17:56 <Sage> I'll try to get the ofono pushed also to review soon.
11:19:44 <lbt> Anything else core- related?
11:20:07 <Stskeeps> nop, i'd like a brief status on copyprj and how badly that's going
11:20:16 <lbt> yep - was going there
11:20:55 <lbt> so I was working on that for a few days last week and it kinda worked
11:21:29 <lbt> I saw various issues that seemed to be slightly random in appearance which made me think it was racy
11:21:58 <lbt> it would sometimes report "no source", sometimes build, once it even seemed to work
11:22:22 <lbt> digging deeper part of the problem is the rdelete really doesn't clean up too well
11:22:35 <lbt> it leaves source trees hanging about and stuff
11:22:37 <Stskeeps> rdelete?
11:22:47 <lbt> well, project delete
11:22:56 <lbt> rdelete is the osc command
11:22:58 <Stskeeps> right
11:23:19 <lbt> so I dug into what's going on and the source handling was doing weird things
11:23:35 <lbt> eg it added revisions to the source history
11:23:42 <lbt> as in source/target
11:24:05 <lbt> so after a copy, the original src had a new revision in it!
11:24:20 <lbt> also there are undocumented things like "makeolder"
11:24:28 <lbt> which ... I don't understand
11:24:36 <lbt> so making sure I don't break it is hard
11:24:56 <lbt> copy "withhistory" also behaves differently to without history
11:25:25 <lbt> so I'm going into how OBS manages source revisions at the moment (well, when I go back to it)
11:25:35 <lbt> and trying to get my head round it
11:25:53 <lbt> this will be useful in handling git based source though
11:26:03 <lbt> so I'm not thrilled but it's not wasted learning
11:26:22 <lbt> it also explains things like what "nosharedtrees" means :)
11:26:34 <Stskeeps> :nod:
11:26:55 <Stskeeps> have you tried anything with next step after copyprj yet, or have you just tried to stablise it so far?
11:26:56 <lbt> so ... summary ... progress is slow but I think I understand what needs doing
11:27:09 <lbt> no, I think that once it works we'll be good
11:27:15 <Stskeeps> ok
11:27:27 <Stskeeps> you dare to give an ETA?
11:27:48 <lbt> not yet - I'm on SDK for a couple of days
11:27:57 <lbt> I would say end of next week seems reasonable
11:28:01 <Stskeeps> ok
11:28:12 <lbt> gives me a bit on SDK/tools and then another dive int
11:28:15 <Stskeeps> we need to find a way to have QA able to do their work before that, then
11:28:34 <Stskeeps> as i'm getting worried we might be slowing down their passion for it by our delays :)
11:28:35 <lbt> in terms of building images?
11:28:39 <Stskeeps> yeah, for example
11:28:42 <Stskeeps> even non-automatic ones
11:28:52 <lbt> IMG should be able to do this
11:29:09 <lbt> I think mic should be able to handle 2 repos
11:29:18 <lbt> note: not can handle ... should handle
11:29:27 <Stskeeps> :nod:
11:29:55 <lbt> I don't think this is a 2 man job - too much hacking about
11:29:57 <Stskeeps> the way the images are created are of less concern for qa, at least
11:30:11 <lbt> so getting phaeron to look at mic/img may make sense
11:31:10 <lbt> so ... SDK ?
11:31:37 <Stskeeps> ok
11:31:40 <lbt> or anything else on the copyprj or mic?
11:31:57 <Stskeeps> SDK progres would be good?
11:32:48 <lbt> #info work on OBS copyproj to enable automated image building for QA was slow. It's been put on hold whilst some SDK work is done.
11:33:07 <lbt> So on that side I want to do better SDK releases
11:33:21 <Stskeeps> oh, and tools releasing would be good to discuss as well
11:33:26 <lbt> right now we have a kind of devel/test/stable but no named releases
11:33:31 <Stskeeps> :nod:
11:33:32 <lbt> *g*
11:34:13 <lbt> So moving SDK to use an update script (probably generic, not complex) that curls latest and updates the repos
11:34:39 <Stskeeps> works for me
11:34:43 <lbt> then identify what releases of what projects are in an SDK
11:34:52 <lbt> which means Tools needs releases
11:35:13 <lbt> so I need a release process/method for that
11:35:25 <Stskeeps> perhaps similar-ish to mer releases?
11:35:37 <Stskeeps> we could expand mer release tools to be even for hw adaptations too
11:35:45 <Stskeeps> so we can do Nemo releases too
11:35:51 <lbt> yeah - I'm not sure about replicating MDS - but it solves src issue and then we treat Tools as a "UX"
11:36:31 <lbt> OK - you've swayed me ... MDS based ... but maybe not implement that this week
11:36:49 <lbt> because the other thing is that all the tools need some sane git repos
11:37:12 <lbt> I had really wanted to avoid that untl I'd sorted the pristine git approach - but meh
11:37:24 <Stskeeps> :nod:
11:38:08 <lbt> then minor things like actually doing some tools update (done git's trivial fix) for things like sb2 and spectacle
11:39:00 <lbt> I don't have a set of regression tests really - it would be nice to try builds against old Mer releases
11:39:29 <Stskeeps> yeah, we need a small test sets of sdk
11:39:36 <Stskeeps> just to sanity check it
11:39:43 <lbt> the wiki runthrough is my sanity check
11:39:52 <lbt> I can script/automate that
11:39:53 <Stskeeps> ok
11:40:06 <Stskeeps> script = make possible in testrunner, ideally
11:40:11 * Stskeeps sips coffee
11:40:12 <lbt> would be good
11:40:29 <lbt> but it doesn't check builds against say January Mer for the TVOS guys
11:41:11 <Stskeeps> :nod:
11:41:26 <lbt> so that's my current SDK work - and probably improve the docs
11:41:52 <lbt> oh, and I don't like how the kickstarts need a new SDK to make them - I may do that differently
11:42:14 <lbt> I want to use an old SDK to make kickstarts for any random Mer release
11:42:22 <Stskeeps> :nod:
11:43:13 <lbt> that's all I've bitten off for this week anyhow ;/
11:43:33 <Stskeeps> good work so far
11:44:36 <lbt> well, this should kinda form the basis of a Mer-based product
11:44:43 <lbt> if you squint :)
11:45:28 <Stskeeps> i think we're doing good on technical side, but our thunder may be a bit gone by now, so we need to improve our web presense as well
11:45:53 <lbt> I agree
11:46:19 <Stskeeps> and advertise on our abilities
11:46:30 <lbt> I was hoping to use qtpi stuff - but the timing and workload made that hard
11:46:34 <Stskeeps> :nod:
11:46:55 <Stskeeps> perhaps even collect testimonials or whatever..
11:46:59 <lbt> I'd still like to have a "make a product based on mer/qtpi" though
11:47:06 <Stskeeps> sure
11:47:11 <Stskeeps> i'm going to make a presentation about that
11:47:11 <Stskeeps> :P
11:47:30 <Stskeeps> https://wiki.tizen.org/wiki/OSDev/MIC btw
11:47:31 <lbt> I've heard comments about ease of getting-going
11:47:53 <lbt> and 'productising' our systems is important
11:48:22 <Stskeeps> :nod:
11:48:33 <Stskeeps> perhaps collect a series on mailing list?
11:48:51 <Stskeeps> of testimonials
11:49:07 <lbt> slaine has given an OK for their company
11:49:14 <lbt> so I need to take him up on that
11:49:20 <lbt> I think I could push that by LWN
11:49:50 <lbt> maybe get it out to some other outlets too - see who's covered Mer in the past
11:50:17 <Stskeeps> :nod:
11:50:26 <lbt> I'll get Denise to google mentions
11:50:26 <Stskeeps> outreach group, perhaps
11:50:48 <lbt> Ash may be of help there
11:51:10 <Stskeeps> perhaps, yeah
11:52:08 <Stskeeps> okay, anything else
11:52:09 <Stskeeps> ?
11:52:34 <lbt> sb2 and mer-obs
11:53:03 <lbt> I'm looking to base on 2.3.0 release
11:53:16 <lbt> using merproject as the github repo
11:53:21 <Stskeeps> ok
11:53:49 <Stskeeps> i need to sort out how we can do a reasonable transformation from sb2-old to sb2-new
11:53:52 <Stskeeps> as well
11:54:14 <lbt> as obs needs to keep building sb2-old
11:54:22 <lbt> ?
11:54:28 <Stskeeps> yeah, that's the idea
11:55:02 <lbt> only for one or 2 mer releases though
11:55:07 <Stskeeps> yeah..
11:55:21 <Stskeeps> i think a workaround could be done
11:55:35 <Stskeeps> as sb2install = install this x86 package and this x86 package alone
11:56:36 <lbt> OK
11:57:12 <lbt> I've not done much wrt a proper 2.3.0 based mer-obs release
11:57:16 <Stskeeps> :nod:
11:57:26 <Stskeeps> should be rebase and solving some conflicts
11:57:27 <Stskeeps> and validation
11:57:28 <lbt> maybe we should get one out so it's 2.3.0-Mer1
11:57:44 <lbt> and that does current-style sb2
11:57:51 <lbt> and 'works'
11:58:04 <lbt> then we have a stable-ish base to work against
11:58:12 <Stskeeps> well, that's the idea
11:58:17 <Stskeeps> i would like to see 2.3.0 based -first-
11:58:22 <Stskeeps> then sb2-b1 afterwards
11:58:33 <Stskeeps> as it really depends on b1 upstreaming too
11:58:34 <lbt> it's in merproject now - but not packaged and tested
11:59:22 <Stskeeps> ok, let's wrap up
11:59:30 <Stskeeps> thank you all for coming
11:59:35 <Stskeeps> #endmeeting
11:59:55 <Stskeeps> ..
11:59:57 <Stskeeps> lbt could do that
11:59:58 <Stskeeps> i guess :0
12:00:42 <lbt> #endmeeting