11:00:18 <Stskeeps> #startmeeting Mer release meeting 10/6/2012
11:00:18 <MerBot> Meeting started Tue Jul 10 11:00:18 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
11:00:18 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00:32 <Stskeeps> welcome to another week of mer release management meeting
11:00:43 <Stskeeps> #info copyproject works!! - and is fast.
11:00:51 <Sage_> o/
11:00:52 <Stskeeps> #info thanks to phaeron's good work
11:01:26 <Stskeeps> however, it took longer time than anticipated, so i'd like to declare an early warning that we will slip on release date to do this properly finally
11:01:27 <lbt> \o
11:01:41 <Stskeeps> i propose new release date 19th, instead of 12th
11:02:01 <lbt> agreed
11:02:12 <Sage_> agreed
11:02:16 <phaeron> hello
11:02:25 <Sage_> any schedule when the review stuff starts to roll again?
11:02:38 <Stskeeps> soon enough, now that we have copyproject i can start including changes, test them, etc
11:02:43 * lbt actually wonders if a release on 19th isn't tight
11:02:58 <Stskeeps> lbt: i think we'll go for low cost variant, test with a couple of important changes
11:03:07 <Stskeeps> but not MDS2, for example
11:03:31 <lbt> OK... that may help enough
11:04:05 <Stskeeps> ie, that we do it through copyproject from A+1 to A+2, etc
11:05:49 <Stskeeps> #agreed Release date moved to 16th July to ensure a stable release, and have things in order, after copyproject delays
11:06:00 <lbt> fits in with iekku's bug-squash on 18th too
11:06:02 <lbt> 19th btw
11:06:14 <phaeron> yeah let's just put it through its paces slowly so we can weed out bugs
11:06:20 <Stskeeps> yeah
11:06:33 <lbt> the #agreed I mean ... 19th
11:06:46 <lbt> since that'll go in the email summary :)
11:07:03 <Stskeeps> #agreed 19th july, not 16th
11:07:23 <Stskeeps> so the idea is, that from now on, releases are made with tagging even the smallest releases, a copyproject from previous release is done, source of the target project is changed to point to new tag
11:08:40 <phaeron> cool tagging means every change is tracked
11:09:24 <phaeron> and bisection is easy if I understand correctly
11:11:18 <Stskeeps> yeah
11:12:01 <Stskeeps> i'll start out slow, semi-manual with mappings.xml adjustments
11:12:36 <Stskeeps> and then we can optimize process as we go
11:12:46 <phaeron> also ping us about the process stuff
11:12:49 <Stskeeps> yes
11:12:52 <lbt> I think we need to update BOSS too
11:13:00 <Stskeeps> yes, please do that soon if possible
11:13:30 <lbt> phaeron, shall we target that for post OBS-release ?
11:14:12 <Stskeeps> can somebody please find out why fe stalls so much?
11:14:22 <Stskeeps> or somehow get it on a higher amount of RAM
11:14:34 <lbt> I don't think it's RAM - but we'll look
11:14:37 <Stskeeps> it's not my expertise
11:14:59 <phaeron> ok so roadmap obs beta release --> upgrade / deploy --> upgrade / deploy boss and friends .. ?
11:15:00 <lbt> our monitoring solution is only partly deployed
11:15:25 <lbt> phaeron: maybe ... lets see other things too
11:15:30 <lbt> and plan at the end
11:15:55 <lbt> shall I add some stuff now or is there more on this topic
11:16:15 <Stskeeps> i don't have anything more, but the fe stalls will compromise CI ability at least
11:16:18 <Stskeeps> as BOSS can't reach it
11:16:45 <lbt> yep - so high prio
11:16:48 <Stskeeps> yes
11:17:03 <lbt> #info SDK got to 6.0.1 : needs some TLC, extra packages and testing
11:17:11 <lbt> Some outstanding bugs need fixing but I think they're all known
11:17:27 <lbt> The problems that exist are really impacting people
11:17:47 <lbt> the upgrade path is dodgy as it relies on an existing link to Testing
11:17:57 <lbt> the linked image is old
11:18:28 <lbt> so overall ... a bit crufty and some polish is high prio as it impacts a lot of new users and influences opinion
11:18:44 <Stskeeps> yes
11:19:17 <lbt> any other comments / suggestions on SDK?
11:19:29 <Sage_> lbt: is there changelog somewhere?
11:19:29 <Stskeeps> needs test cases, but i've volunteered to help with that
11:19:39 <Stskeeps> my weekend went, erm, a little different than expected
11:19:48 <lbt> Stskeeps: indeed
11:20:00 <Stskeeps> oh
11:20:02 <Stskeeps> on a sidenote
11:20:12 <lbt> Sage_: not really, the release/promotion process isn't great and makes deltas not easy
11:20:19 <Stskeeps> we need to figure out why our phosts don't grok qemu-kvm -host cpu
11:20:29 <Stskeeps> for workers
11:20:46 <lbt> log an OBS bug ?
11:20:47 <Stskeeps> also, it is my feeling that the workers are slower/not working properly with tmpfs in current setup
11:20:50 <Stskeeps> yes
11:21:13 <lbt> I haven't started the migration to new phosts yet :(
11:21:58 <lbt> #info generic release script being worked on
11:22:10 <lbt> Needs a bit more definition in specification and then used to release Nemo
11:22:11 <lbt> I'm using it for SDK and have spotted some issues. It needs a re-write now.
11:22:30 <lbt> Sage_: this is where I'd like to manage changelogs
11:22:48 <Stskeeps> lbt: what phost numbers are they
11:22:49 <Stskeeps> ?
11:22:50 <lbt> At the moment that's hard
11:22:53 <lbt> 6/7
11:23:16 <lbt> I was planning to puppet deploy them
11:23:21 <Stskeeps> ok
11:23:28 <lbt> we need to keep many workers in kinda-sync
11:24:20 <lbt> the release scripts we have are a bit inefficient
11:24:52 <lbt> and leave stuff lying about (which is good for when they go wrong but messy later)
11:25:21 <lbt> I've not had the bottle to use the new one for a Mer release yet :)
11:25:26 <lbt> so WIP
11:25:41 <lbt> comments?
11:25:59 <lbt> oh, I feel we need to address a pkg DB as part of this work
11:26:06 <lbt> DB != mysql
11:26:29 <lbt> it's just a way to store "what's in a release"
11:26:57 <lbt> comments?
11:27:16 <phaeron> bottle ?
11:27:26 <lbt> balls, cohones
11:27:47 <phaeron> ok.. didn't know bottles were for people with guts :D
11:27:47 <lbt> ie I'm too scared :)
11:28:06 <phaeron> I am trying out meego's repodiff tool
11:28:08 <lbt> I'll educate you in english euphimisms
11:28:17 <lbt> yeah, that could be a good solution
11:28:20 <phaeron> which is actually redhat's
11:28:34 <phaeron> but so far it's just crapping out
11:28:48 <phaeron> I'll report when I get it working or rewrite it :D
11:29:12 <lbt> OK - that may be part of release tools then
11:29:18 <lbt> moving on?
11:29:28 <lbt> #info QA tools needs ruby in Tools. Sage is working on this but having problems
11:29:36 <lbt> I've said we'll use Suse packagin stack as the base for our ruby since
11:29:38 <lbt> we have Suse ruby gems for BOSS and probably for OBS too
11:29:50 <Sage_> :nod:
11:30:17 <lbt> I sympathise with the pain .... and phaeron, alterego and I probably need to step in and help since we've been burnt before
11:30:35 <lbt> it's a priority thing and I think QA is high
11:30:41 <lbt> (what isn't?)
11:31:31 <lbt> Sage has done some work on setting out some notes : https://wiki.merproject.org/wiki/Packaging/Ruby
11:31:53 <phaeron> yeah was just starting to look at that in #mer
11:32:04 <phaeron> asked Sage_ a question there
11:32:06 <lbt> the problem currently lies in the tooling pulled from upstream
11:32:54 <lbt> darix and adrian in #obs verified the approach iirc
11:33:32 <Sage_> yes, they said it should work.
11:33:37 <lbt> this is blocking tdriver deployment to the device?
11:33:56 <lbt> and needs to be in the Tools/SDK release
11:34:06 <Sage_> well, there is workaround for it but that would mean more work later for us if opensuse packaging doesn't work.
11:34:21 <lbt> yeah - and we're too busy to ever go back
11:34:35 <lbt> if we do it wrong the first time it takes *years* to put it right
11:34:45 * lbt looks at package version numbering ....
11:35:21 <lbt> so that's one reason I'm reluctant to take hacks - and I know you hate me and agree with me at the same time :D
11:35:56 <lbt> so I'm kinda thinking that ruby should be a release-blocker for next SDK release
11:36:10 <lbt> that puts pressure on everyone to help out
11:36:25 <lbt> 'cos we all know how important a non-broken SDK is
11:36:49 <lbt> can you all agree/disagree so I know you're listening?
11:37:08 <phaeron> ack
11:38:04 <Sage_> yes
11:38:10 <Sage_> sry, ack :)
11:38:22 <lbt> and is Stskeeps cloud-gazing again?
11:38:30 <Stskeeps> sheep-gazing, perhaps
11:38:47 <lbt> don't say that anywhere near Wales....
11:39:30 <lbt> OK then
11:40:28 <lbt> #agreed ruby/QA work is a release blocker for next SDK release
11:41:08 <lbt> moving on
11:41:26 <lbt> #info sample Mer HA focs for N900 is almost done, N950, ExoPC, VM and RasPi to follow
11:41:37 <Stskeeps> iekku: how do i search for release blockers?
11:41:50 <Sage_> lbt: where do you have those sample Mer HA's ?
11:41:59 <lbt> it's not that big - but I keep removing things to keep it simple
11:42:02 <Sage_> lbt: Mainly pondering if you use the Nemo HA's for those?
11:42:09 <lbt> I do
11:42:13 <lbt> https://wiki.merproject.org/wiki/Getting_Started
11:42:16 <Sage_> ok. glad to hear.
11:42:37 <Sage_> ah
11:42:39 <Sage_> nice
11:42:40 <lbt> I would be keen to re-arrange some Nemo wiki pages too if possible
11:42:51 <Sage_> sounds good
11:43:23 <iekku> Stskeeps, wait a sec
11:44:15 <lbt> OK, I'll break them down and get you to review them
11:44:28 <iekku> https://bugs.merproject.org/buglist.cgi?query_format=advanced&field0-0-0=flagtypes.name&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&type0-0-0=substring&value0-0-0=Release
11:44:50 <iekku> there's the ones which are or have been proposed to be release blockers
11:44:54 <Stskeeps> ok, let's walk through them one by one
11:45:02 <lbt> let me wrap up
11:45:10 <Stskeeps> 412: https://bugs.merproject.org/show_bug.cgi?id=412 - openssl is not installable on all architectures
11:45:19 <lbt> Stskeeps: sec
11:45:21 <Stskeeps> Sage_: did you have a fix for this?
11:45:35 <Sage_> yes
11:45:44 * lbt checks to see if he's on mute
11:45:47 <Stskeeps> please refer to it in the bug report and change assignee
11:45:55 <Stskeeps> lbt: yes?
11:45:55 <Stskeeps> :P
11:46:01 <lbt> ty
11:46:19 <lbt> so the HA adaptation/prototype is driven by a meeting with Orange Labs and to support easy prototyping
11:46:37 <lbt> which is why I'm giving it high importance
11:46:47 <lbt> They plan to start on this tommorrow
11:46:58 <Stskeeps> sounds good
11:47:05 <lbt> and will be doing it until Tizen get their act together.
11:47:06 <Sage_> Stskeeps: I fixed it before I kewn about the bug report. Will infrom there.
11:47:12 <Stskeeps> Sage_: k
11:47:14 <lbt> They've promised feedback too
11:47:25 <lbt> one final item
11:47:35 <lbt> #info I really want to introduce new package numbering scheme *SOON*
11:47:56 <lbt> this will impact our downstreams
11:48:07 <lbt> again, if we don't do it soon they will suffer a lot
11:48:17 <Stskeeps> i agree, past BOSS upgrade and new release mechanism
11:48:24 <Stskeeps> i've run into the issue, again, recently
11:48:37 <lbt> yep - wanted it as a point for our planning before we wrap up
11:49:02 <phaeron> lbt: we really need that too
11:49:06 <phaeron> the version numbering scheme
11:49:14 <phaeron> with extraversion etc ..
11:49:16 <lbt> I know ... :)
11:49:18 <phaeron> right Sage_ ?
11:49:37 <lbt> I fixed a bug in OBS that prevented it working BTW
11:50:08 <Sage_> phaeron: ye
11:50:10 <Sage_> *s
11:50:30 * lbt decides not spend any time on the git packaging though it may be useful to do at versioning change time
11:50:47 <lbt> I'm done ...
11:50:54 <lbt> sorry there was a lot
11:51:12 <Stskeeps> Sage_: https://bugs.merproject.org/show_bug.cgi?id=424 - did we have a fix for this?
11:51:20 <Stskeeps> it seems to happen if ca-certificates and openssl are installed out of order
11:51:25 <Stskeeps> due to symlink madness
11:51:29 <phaeron> lbt: thanks, please also make sure you bring that up in an email to us
11:51:29 <Sage_> Stskeeps: this is the same as 412 I think
11:51:35 <Stskeeps> Sage_: no, different
11:51:37 <Sage_> The following package is going to be REMOVED: openssl
11:51:41 <Stskeeps> Sage_: look further down
11:51:52 <lbt> Stskeeps: that could be due to mer-sdk script too
11:52:01 <Sage_> Stskeeps: ca-certs fail if openssl isn't there as it uses it
11:52:02 <Stskeeps> lbt: i've encountered it on device, i think
11:52:11 <Stskeeps> Sage_: ok, does ca-certificates require openssl now?
11:52:16 <Sage_> openssl binary is not there
11:52:21 <lbt> ah, that's good then
11:52:48 <Sage_> ah, hmmp
11:52:54 <Sage_> it was only build requirement
11:53:09 <Sage_> not sure actually after all
11:53:48 <Sage_> but it still might be related I would say.
11:53:52 <Stskeeps> ok
11:54:27 <Stskeeps> lbt: 289 hasn't passed review yet, so i think no release blocker at this time?
11:55:02 <lbt> OK
11:55:10 <lbt> should we try to get it in?
11:55:33 <Stskeeps> https://bugs.merproject.org/show_bug.cgi?id=415 - cosmetic, not a release blocker
11:55:36 <Stskeeps> just very irritating
11:55:55 <Stskeeps> lbt: let's see how things go
11:56:02 <Stskeeps> iekku, please make 412, 424 release blockers, refuse for 289, 415
11:59:39 <Stskeeps> OK, anything else?
12:00:49 <lbt> as phaeron said... planning?
12:01:03 <lbt> we have a number of big tasks that need to be ordered
12:01:18 <Stskeeps> ok, so, BOSS upgrade would be good to do while we're pausing CI anyway
12:01:46 <Stskeeps> and not deploying the new process until that is done
12:01:48 <iekku> Stskeeps, ok
12:02:01 <Stskeeps> can anybody commit to a new boss installation?
12:02:14 <lbt> so order: OBS, Ruby/QA, SDK, BOSS
12:02:37 <Stskeeps> stalls, BOSS, SDK, Ruby/QA IMHO
12:02:44 <Stskeeps> stalls, OBS, BOSS, i mean
12:02:54 <lbt> no SDK?
12:03:25 <Stskeeps> fe stalls, OBS release, BOSS, SDK, Ruby/QA
12:03:33 <Stskeeps> in order of priority
12:03:39 <lbt> Ruby/QA blocks SDK
12:03:42 <lbt> as agreed
12:03:44 <Stskeeps> ok
12:03:51 <Stskeeps> i'm not 100% on why, since it's a new feature
12:04:00 <Stskeeps> but ok, if that's what people agreed on
12:04:10 <lbt> because it raised prio of QA tool implementation
12:05:06 <phaeron> boss doesn't depend on obs update
12:05:31 <Stskeeps> from my perspective i need releasing up and running, so, continuing work on copyproject-using process, fe cannot stall as it means entire process breaks down, OBS release is good for also validating copyproject patches
12:05:41 <Stskeeps> we also need modifications to mer release scripts
12:06:19 <Stskeeps> to do per-snapshot releases, from new repos
12:06:19 <Stskeeps> s
12:07:41 <lbt> phaeron: not a depend, an order of prio for work
12:07:47 <phaeron> ok
12:08:05 <lbt> I'm happy with fe stalls, OBS release, BOSS, Ruby/QA, SDK
12:08:23 <lbt> Sage_: that pushes an assist on Ruby out for a bit
12:10:02 <phaeron> we can work in parallel
12:10:16 <phaeron> I am interested in helping with the ruby packaging
12:10:26 <phaeron> though I know I'll regret that
12:10:28 <phaeron> :D
12:10:32 <lbt> sure - that can effectively delay delivery of both streams though
12:11:10 <Stskeeps> SDK will need a new mer release, too, right?
12:11:13 <Stskeeps> to solve openssl problems etc
12:11:32 <lbt> yes
12:11:44 <lbt> and now that's pushed back of course
12:12:06 <lbt> so that fits
12:12:11 <Stskeeps> ok
12:12:15 <Stskeeps> we have a plan then?
12:12:23 <lbt> #agreed Plan:  fe stalls, OBS release, BOSS, Ruby/QA, SDKRuby/QA
12:13:08 <lbt> meh ... was preparing that but it's close enough
12:14:54 <phaeron> brb
12:14:57 <Stskeeps> alright
12:15:00 <Stskeeps> thank you all for coming
12:15:28 <Stskeeps> #endmeeting