11:01:07 <Stskeeps> #startmeeting Mer release management meeting 12/6/2012
11:01:07 <MerBot> Meeting started Tue Jun 12 11:01:07 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
11:01:07 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:01:18 <lbt> o/
11:01:21 <Stskeeps> o/
11:01:48 <lbt> Sage ------|=
11:01:54 <lbt> phaeron ------|=
11:01:55 <Stskeeps> not around, vacation
11:02:09 <lbt> ah yes ... so stabbing him with a sword won't help
11:02:47 <Stskeeps> #info ARMv6 had been broken since 0405, fixed by disabling Cortex string routines in glibc for armv6
11:03:15 <Stskeeps> #info connman 1.1 merged, locale archives fixed (295), libjpeg-turbo-devel (225)
11:04:07 <Stskeeps> #info one testing round before release probably good idea, snapshot tomorrow?
11:04:11 <Stskeeps> prerelease
11:04:18 <phaeron> was on phone
11:04:21 <phaeron> 'sorry
11:04:24 <lbt> OK
11:04:26 <lbt> phaeron: :)
11:04:32 <iekku> sage is on vacation
11:04:40 <phaeron> ouch stabbed
11:06:50 <Stskeeps> so what's new from your side? i was gone for a week
11:07:19 <phaeron> I was looking at mds to see if it can run without git
11:07:26 <phaeron> can it wrap a bare repo ?
11:07:39 <Stskeeps> it doesn't need it as such for non-source
11:07:48 <Stskeeps> for source it does, atm
11:07:59 <Stskeeps> but i think the intel guys patched it to not use git
11:08:04 <phaeron> yeah never mind source
11:08:29 <phaeron> so would be worth looking into
11:08:52 <phaeron> as kind of a dynamic download on demand
11:09:26 <Stskeeps> we have one proposed release blocker, https://bugs.merproject.org/show_bug.cgi?id=289
11:09:51 <Stskeeps> i think i'll not grant that for this release but it should be in next cycle s
11:09:54 <Stskeeps> tart
11:11:38 <Stskeeps> lbt, please what you just said in #mer in here please
11:12:04 <lbt> d'oh
11:12:15 <lbt> 289 is a release blocker since a release shouldn't happen if it's half-accepted
11:12:35 <lbt> but it's not merged yet so we can ignore it for this release
11:12:58 <iekku> would be good if you could grant or decline the release_blocker status
11:13:13 <Stskeeps> for this one, decline
11:13:18 <Stskeeps> but we will review it for next
11:13:18 <lbt> mmm
11:13:23 <lbt> can you leave it pendin
11:13:31 <Stskeeps> https://bugs.merproject.org/buglist.cgi?query_format=advanced&field0-0-0=flagtypes.name&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&bug_status=RESOLVED&bug_status=RELEASED&bug_status=VERIFIED&bug_status=CLOSED&type0-0-0=substring&value0-0-0=Release_Blocker
11:13:36 <Stskeeps> that's what was reported
11:13:51 <Stskeeps> i fixed 349, 377 so maybe that should have been under my assignee
11:16:37 <Stskeeps> so, what about lbt's status/prjcopy?
11:16:46 <lbt> OK
11:17:01 <lbt> # info Mer release tools rewrite - using them to do SDK, Tools and OBS :  http://gitweb.merproject.org/gitweb?p=mer/release-tools.git;a=shortlog;h=refs/heads/lbt
11:17:28 <lbt> so I wanted to be able to do releases of Tools to combine with Core to make SDK
11:17:45 <lbt> #info Mer release tools rewrite - using them to do SDK, Tools and OBS :  http://gitweb.merproject.org/gitweb?p=mer/release-tools.git;a=shortlog;h=refs/heads/lbt
11:18:00 <lbt> having done that...
11:18:04 <lbt> #info SDK : now release based, new tools (needs a new release with some updates as mentioned in http://www.mail-archive.com/mer-general@lists.merproject.org/msg00548.html )
11:18:36 <lbt> This provides a trivial 'update' script : raises an issue: how should we (and oss-style vendors) handle updates?
11:19:23 <Stskeeps> :nod:
11:19:42 <Stskeeps> a proper implementation of this kinda relies on the ability to do builds and branches
11:19:52 <lbt> yes
11:19:58 <lbt> #info Mer OBS setup-obs.sh script has been updated to use new OBS release (which isn't done yet)
11:20:05 <lbt> sonach reported success with it
11:20:24 <Stskeeps> good
11:20:32 <lbt> unsurprisingly the old version which points to an uncontrolled Testing OBS repo was broken
11:20:59 <lbt> we should soon be able to release/publish any OBS project - not sure we're "doing it right" though
11:21:16 <Stskeeps> i think it's in the right direction for sure
11:21:21 <lbt> OBS 2.3 has capabilities in this area too
11:21:36 <lbt> we should investigate and share if possible
11:22:07 <lbt> on the copyproj
11:22:17 <phaeron> what capabilities
11:22:22 <lbt> OK
11:22:38 <lbt> not 100% sure - Adrian mentioned it and it's to do with making releases
11:22:51 <lbt> read the release notes and marked "must read up"
11:23:09 <phaeron> ok
11:23:15 <phaeron> maybe the patchinfo stuff
11:23:32 <lbt> copyprj: I spent some time on that but had to break for other stuff (and sanity) ... phaeron has had a go and it works for him but not for me :)
11:23:34 <phaeron> and maintenance projects
11:23:47 <lbt> yes, I think it could be those
11:24:25 <phaeron> last test I did with copyprj was quite big and it worked. I will move on to copyprj + linked prj
11:24:38 <phaeron> lbt: are you doing a copyprj form mds to obs ?
11:24:54 <lbt> yes
11:24:59 <lbt> it doesn't work
11:25:01 <phaeron> and you see that working ?
11:25:09 <Stskeeps> 'from mds'?
11:25:15 <lbt> I'm trying one using cobs/mds
11:25:40 <phaeron> I mean are you doing a project copy from mds directly to an obs ?
11:26:14 <lbt> https://gist.github.com/2913004
11:26:26 <lbt> that's my setup script
11:26:34 <lbt> it makes projects that build against mds
11:26:35 <phaeron> everytime you paste that gist I get fits :D
11:26:43 <lbt> why?
11:26:50 <Stskeeps> that's copypac, not copyprj?
11:27:00 <lbt> "setup script"
11:27:05 <Stskeeps> ok
11:27:11 <lbt> it defines starting position pretty clearly
11:27:11 <Stskeeps> and what is your copyprj command line?
11:27:15 <lbt> then I do a copyprj
11:27:51 <lbt> I use :  osc-wrapper.py --debug -t -A https://obsfe.dgreaves.com:444 copyprj -n -b MyMerUx MyMerUx44
11:28:14 <Stskeeps> ok
11:28:23 <lbt> -n == now == nodelay
11:28:33 <lbt> -b == binaries == withbinaries
11:28:59 <phaeron> ok so this means you are not doing copyprj from mds to obs
11:29:01 <Stskeeps> and we're sure it sends the correct url?
11:29:06 <lbt> POST https://obsfe.dgreaves.com:444/source/MyMerUx44?comment=osc+copyprj+from+project%3AMyMerUx&oproject=MyMerUx&cmd=copy&nodelay=1&withbinaries=1
11:29:27 <Stskeeps> ok
11:29:40 <phaeron> the only difference in the POST is I don't add a comment
11:29:48 <lbt> it then "does stuff"
11:29:54 <lbt> and I get variable results
11:29:58 <phaeron> osc -A appl api -X POST '/source/Project:copy6?cmd=copy&nodelay=1&oproject=home:Admin&withbinaries=1'
11:30:04 <lbt> so I do it 3 times to 3 target projects
11:30:27 <lbt> 1 succeeds, 1 rebuilds, 1 says "failed" with no-source uploaded
11:30:38 <phaeron> so I have done that 6 times and got same working results.
11:31:01 <phaeron> the only difference between us is that comment , and that you _build_ directly against MDS
11:31:10 <phaeron> I build against mds through cobs
11:31:15 <lbt> the difference so far is that phaeron uses a build target of  cobs:Mer:fake:Core:i586
11:31:36 <lbt> I use MerDS:Core:i586
11:31:56 <Stskeeps> right, MerDS directly is more bound to be reliable i would think
11:32:02 <Stskeeps> and a typical setup
11:32:06 <lbt> yes
11:32:18 <lbt> but if his works I should reproduce to verify
11:32:22 <lbt> then we can isolate
11:33:09 <phaeron> I don't agree. if merds breaks because it is not implementing some corner case of obs-obs link then it is merds's faulty
11:33:46 <phaeron> anyway I will setup mds here and test that scenario
11:33:58 <lbt> what don't you agree with? I'm going to try your approach
11:34:09 <phaeron> I don't agree with what Stskeeps said
11:34:34 <lbt> mmm
11:34:46 <Stskeeps> i just meant that MDS linked directly is the 'typical' mer setup
11:35:03 <lbt> yeah ... local LAN = more reliable, not less buggy :)
11:35:11 <lbt> MDS could have bugs
11:35:12 <Stskeeps> and MDS-OBS-OBS might be prone to failures, or sometimes slowness reducing chance of races
11:35:15 <Stskeeps> but yes
11:35:17 <Stskeeps> MDS might have bugs
11:35:26 <phaeron> ok we are all saying same thing
11:35:54 <Stskeeps> yes
11:35:54 <Stskeeps> :P
11:36:30 <Stskeeps> sounds like a plan forward then
11:36:56 <lbt> yup
11:37:04 <Stskeeps> i vote for postponing release until monday in order to get proper testing done
11:37:08 <Stskeeps> with a prerelease tomorrow
11:37:26 <lbt> OK
11:37:29 <phaeron> k
11:37:59 <Stskeeps> alright, anything else to discuss?
11:38:05 <phaeron> no
11:38:58 <lbt> "releases"
11:38:58 <Stskeeps> thank you all for coming then
11:39:05 <Stskeeps> .. mm?
11:39:38 <lbt> well, as I said, there's an issue about releases
11:39:43 <lbt> it affects Nemo too
11:39:58 <lbt> getting info into a release about what release it is is hard
11:40:31 <lbt> asking a Mer device what release it has is not defined
11:40:46 <lbt> update vs upgrade
11:41:01 <Stskeeps> that is correct
11:41:20 <lbt> kinds of "release" ... static and updated
11:41:35 <lbt> Mer core releases are static so people can rely on them
11:41:45 <lbt> Nemo ones are dynamic so customers see updates
11:42:06 <lbt> err, kinds of release repo
11:42:26 <Stskeeps> OS updates are a hard problem :)
11:42:36 <lbt> hence the need to discuss...
11:42:37 <Stskeeps> i think it's worth starting a discussion thread on
11:42:41 <Stskeeps> on mailing list
11:42:56 <lbt> since I've been looking at createrelease scripts with an eye on what vendors want
11:43:00 <Stskeeps> will you start it?
11:43:04 <lbt> OK
11:43:25 <lbt> any thoughts here to prime it - or are we busy?
11:43:38 <lbt> preparing birthday treats perhaps?
11:43:46 <Stskeeps> well, some research into existing SSU methods at least
11:43:50 <Stskeeps> and old plans for meego
11:44:00 <Stskeeps> i need to go have some food before i collapse on the keyboard:P
11:44:02 <lbt> also suse approaches
11:44:12 <lbt> since OBS may well assist
11:44:17 <lbt> OK
11:44:29 <Stskeeps> thanks all for coming
11:44:38 <Stskeeps> #action lbt to start release update discussions
11:44:39 <Stskeeps> #endmeeting