12:01:39 <Stskeeps> #startmeeting Release management meeting 6/3/2012
12:01:39 <MerBot> Meeting started Tue Mar  6 12:01:39 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
12:01:39 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:02:00 <Stskeeps> welcome to another week of Mer releasing
12:02:20 <Stskeeps> #info next release: 20120315
12:02:23 <lbt> o/
12:02:40 <Stskeeps> #info 0.20120315.0.0.1 snapshot in progress today, will appear in _next repositories on COBS
12:03:24 <Stskeeps> please check http://review.merproject.org/#q,status:open,n,z for staged content
12:03:52 <Sage__> o/
12:04:00 <Stskeeps> (the ones marked as accepted but not merged)
12:04:21 <Stskeeps> Sage__: can you update me on the udev one, what's wrong there?
12:04:26 <Stskeeps> it requires new systemd?
12:05:15 <Sage__> Stskeeps: udev requires new systemd because of its .service file
12:05:25 <Stskeeps> ok
12:05:33 <Sage__> also udev doesn't anymore create loopdevices so that should be known
12:05:53 <Sage__> there is new way in kernel that creates those dynamically
12:06:09 <Stskeeps> is that compatible with 2.6.32 kernels?
12:06:29 <Stskeeps> i presume you can still make them
12:06:36 <Sage__> yes you can make them
12:06:48 <Stskeeps> ok, so 'mic' might have problems in a vm setting?
12:06:49 <Sage__> but I would recommend keeping it clear from udev package
12:07:04 <Sage__> Stskeeps: not sure as mic creates loop devices to host
12:07:19 <Stskeeps> ok
12:07:28 <Sage__> AFAIK it doesn't create loops devices inside the 'vm'
12:07:49 <lbt> depends how we setup the SDK
12:08:00 <Stskeeps> of those, i'd like to merge: systemd, udev, openssl, libxml2, llvm, filesystem, libutempter, and mesa with llvmpipe
12:08:13 <Stskeeps> for next prerelease
12:09:03 <Sage__> next meaning .0.0.0.1 ?
12:09:06 <Stskeeps> 0.1
12:09:13 <Stskeeps> ie, our first prerelease
12:09:18 <Stskeeps> where content is stable
12:09:36 <Sage__> so .0.0.1 is called snapshot?
12:09:51 <Stskeeps> yeah
12:09:53 <Sage__> ok
12:10:07 <Stskeeps> http://wiki.merproject.org/wiki/Process#Version_numbers
12:10:08 * Sage__ mixed naming
12:10:42 <Sage_> The mesa packaging needs a bit more work I would say.
12:10:54 <Stskeeps> yes
12:10:58 <Stskeeps> i might have to bring back libGL
12:11:43 <Sage_> it should be called maybe mesa-llvm-* or something and provide mesa-*
12:12:04 <Stskeeps> :nod:
12:12:12 <Stskeeps> and we should have x86 mesa-intel as well
12:12:21 <Stskeeps> in x86 adaptation
12:12:21 <lbt> in core?
12:12:25 <lbt> :)
12:12:43 <Sage_> yes the Nemo's x86 adaptation needs update
12:13:19 <Sage_> could use some help with that btw if someone is interested of debugging it more. But that is something to talk in #nemomobile
12:13:24 <Stskeeps> :nod:
12:14:26 <Stskeeps> i've also been working on MDS and teaching (in #mer) about how MDS2 principles work
12:15:49 <lbt> which I think will fit nicely with the work I'm doing on removing tarballs from the git repos
12:16:05 <Sage_> I fixed the info package dependencies and also updated the nspr and nss (which are depending on each other).
12:16:06 <Stskeeps> :nod: we still need to elaborate a bit on how a more intelligent MDS works
12:16:19 <Sage_> would like to get those in as well to next release if possible
12:16:53 <Sage_> those info package fixes are quite trivial, nss and nspr are a bit bigger.
12:16:58 <Stskeeps> might qualify under 'security'
12:18:06 <lbt> so reading the wiki page... we have until Sunday to make substantive changes
12:19:48 <Sage_> I think I have submitted all of my planned fixes already to review.
12:19:48 <lbt> Also I hate 00:00 as a time .... does that really mean very late saturday night?
12:19:59 <Stskeeps> automation, so it's available for work the next morning
12:20:15 <lbt> yeah - so you meant 23:59 on sunday
12:20:24 <Sage_> Maybe we should say 23:59 saturday?
12:20:25 <lbt> available for monday morning?
12:20:31 <lbt> :)
12:20:39 <Sage_> :P
12:20:40 <Stskeeps> ok
12:20:47 <Sage_> so which one of the dates? :D
12:21:10 <Stskeeps> so think this way.. prerelease comes out from Mer and there's 24 hours for vendor automated systems to build so it's available for their work monday morning
12:21:18 <Stskeeps> and QA
12:21:20 <lbt> got it
12:21:27 <Stskeeps> so, i do mean early sunday morning
12:21:33 <Sage_> sounds good.
12:21:44 * lbt delays all tasks by 1minute
12:23:06 <lbt> "Release happens on Wednesday 00:01 UTC"  ? Thursday?
12:23:38 <Stskeeps> you're right, should be thursday
12:24:20 <lbt> OK .. done being picky now :)
12:24:35 * Sage_ ponders if he should change nemo release to wednesday from thursday then.
12:25:03 <Stskeeps> lbt: this may be more fluent with a proper CI approach though
12:25:08 <Stskeeps> ie, this is very non-automatic
12:25:11 <lbt> agreed
12:25:20 <Stskeeps> in practice we go through several pickups
12:26:06 <lbt> yep - the stuff I'm doing now lets me get a feel for what's happening and I'm thinking about the automation and release as I go
12:26:48 <lbt> thinking about locking systems etc
12:28:22 <lbt> #info Release process schedules clarified on http://wiki.merproject.org/wiki/Process#Release_Process - still a WIP pending automation
12:28:35 <lbt> OK - so any mer-ish RE things? I have git packaging, usr move and version numbering
12:29:03 <Stskeeps> think we're on track for next release so far
12:29:10 <lbt> I'm also using my+Stskeeps' chat logs to do some docs
12:29:47 <lbt> yep, I have the snapshot email ready to send as soon as I hit the button on c.obs MDS
12:31:03 <Stskeeps> (and it starts building..)
12:31:11 <lbt> yep
12:31:49 <lbt> Oh, I should do an SDK update too I guess
12:32:20 <Stskeeps> for .0.0.1? not sure that's needed, except for testing
12:32:38 <lbt> no, I meant a general meeting minutes update
12:32:46 <Stskeeps> ok
12:32:59 <lbt> so, as you've seen from ml I've updated the SDK again :)
12:33:18 <lbt> the wiki page has all the new instructions
12:33:35 <lbt> it now has a one-off 'mount' command to setup bind mounts
12:33:59 <lbt> I hope the instructions are the right balance of detail/brevity
12:34:09 <lbt> I kept the advanced stuff at the bottom of the page
12:34:19 <lbt> I think all the goals are met
12:34:33 <lbt> "simple" things like a nice prompt
12:34:48 <lbt> and more complex ones like multiple concurrent SDKs
12:35:10 <lbt> the bind mount area is a bit of a spaghetti thing
12:35:46 <lbt> but again I've tried to balance hiding the complexity and letting people hack on it
12:36:25 <lbt> I'm certainly happier that you can roll this out to a team of people and have less problems with it
12:36:34 <Stskeeps> :nod:
12:36:51 <lbt> the only weird stuff that I'm missing is I haven't tested things like usb stick mounting
12:36:59 <lbt> ie stick into host, does it appear in SDK
12:37:07 <Stskeeps> if you share /dev..
12:37:21 <lbt> yes, but I mean the mountpoint
12:37:39 <lbt> bind mounts have some strange 'slave/share' mode
12:37:52 <lbt> but frankly.... I'm leaving that until I care more
12:37:53 <Stskeeps> mm
12:38:36 <lbt> Now we have the snapshot I need to look at the SB2 version and import timoph's work
12:39:03 <lbt> that may need some hacking/testing of the merrelease.sh script ...
12:39:28 <Stskeeps> i am looking a bit at how qtonpi is doing their app sdk
12:39:33 <Stskeeps> ie, qt creator
12:40:16 <lbt> #info Platform SDK is at a stable point for non SB2 work. Next step is SB2 enabling it.
12:41:15 <lbt> I would like to see that too - getting something into QtCreator would be nice
12:42:28 <lbt> So Sage_ was talking about usr move this week....
12:42:52 <Sage_> the nss and nspr packages that are in review have already libs moved to /usr/lib from /lib
12:44:05 <Stskeeps> we can try a more concerted approach to that for +4w i guess
12:44:15 <Stskeeps> and get eglibc 2.15 in at same time
12:44:53 <Stskeeps> Sage_: can you get some data on how much stuff has things in /bin, /sbin and /lib?
12:45:23 <Stskeeps> ie, on a typically installed image
12:46:48 <lbt> I'd like to verify the rpm dependency thing too
12:47:21 <Stskeeps> hm?
12:48:02 <lbt> so some rpm package depends on /bin/gawk
12:49:23 <Stskeeps> ah yeah
12:49:36 <lbt> do we keep installing to /bin or install to /usr/bin
12:49:36 <Stskeeps> i wonder how fedora handled that
12:49:55 * lbt wonders if the easy way is to teach rpm ?
12:50:46 <lbt> also if I have a new version of a package which needs /usr/bin/gawk and I'm upgrading just that package
12:51:03 <lbt> and the device has /bin/gawk installed
12:51:35 <lbt> so kinda wondering about handling an upgrade across a /usr moved release
12:52:01 <lbt> https://fedoraproject.org/wiki/Features/UsrMove   FYI
12:53:46 <Stskeeps> :nod:
12:53:48 <Stskeeps> alright, anything else?
12:53:50 * lbt also wonders what this would mean for vendors - especially PA and Nemo (as the most established vendors)
12:54:08 <lbt> maybe we should call a vendor meeting ?
12:54:20 <Sage_> lbt: /usr move you mean?
12:54:22 <Stskeeps> i think prerelease should catch most issues tbh
12:54:23 <lbt> yes
12:54:26 <Stskeeps> ie, a lot of them
12:54:34 <Sage_> lbt: Shouldn't change much in general
12:54:43 <Stskeeps> vendors don't really install that much into /usr anyway
12:54:49 <Stskeeps> err
12:54:50 <Stskeeps> outside
12:54:55 <lbt> Sage_: yeah, but I'm being polite :)
12:55:09 <lbt> or maybe just flag it here...
12:55:40 <Sage_> lbt: :)
12:55:49 <Sage_> lbt: that is good policy
12:56:13 <lbt> Sage_: being polite? :D
12:57:06 <lbt> #info usr-move was agreed in principle a couple of weeks ago. Work is proceeding. We expect to include it in the 0.20120329 release
12:57:13 <Sage_> lbt: :nod: :)
12:57:44 <Sage_> IMO we should first move everything under /lib and then see other things. That should be the easiest one
12:57:53 <Stskeeps> :nod:
12:57:58 <lbt> #action David to schedule a usr-move meeting to discuss any issues with vendors
12:58:12 <Sage_> /bin and /sbin are harder ones as there are hardcoded paths
12:58:46 <lbt> yep
12:59:03 <lbt> also - to what extent do we support zypper up
12:59:36 <lbt> especially since we don't have initramfs per se
13:00:29 <Sage_> I would say that we should at least test between each release how the update works and what are the problems
13:00:52 <Sage_> i.e., install the core and do zypper up and do report what things might break
13:00:57 <lbt> The SDK may be a good place to try this
13:01:05 <Sage_> :nod:
13:01:37 <lbt> Not quite sure how this fits into CI
13:01:58 <Stskeeps> check process
13:02:04 <Stskeeps> one of the checks is upgradeability
13:02:38 <lbt> ideally we'd have a "build rootfs" and "zypper up <pkg> in rootfs of last release"
13:02:49 <Stskeeps> :nod:
13:03:25 <lbt> Stskeeps: yeah - but.... not there yet - so do we need to start doing that manually before approving?
13:03:46 <Stskeeps> too much workload, need automation
13:03:57 <lbt> aye
13:04:57 <lbt> #action improve CI to do both rootfs builds and "zypper up <pkg>" tests
13:05:40 <lbt> on the positive side I'm finding the rabbit holes are usually less deep now
13:06:04 <lbt> I think that's a sign that the work fixing up the foundations is paying off
13:06:57 <lbt> I'm guessing that it's too late to do an update on git+packaging ... I'll bring it up in #mer as I put some docs together
13:07:08 <Stskeeps> :nod:
13:07:10 <Stskeeps> let's finish up
13:07:16 <Stskeeps> thank you all for coming
13:07:30 <lbt> #info Git packaging work is progressing nicely
13:07:40 <Sage_> thx, cya
13:07:46 <Stskeeps> #endmeeting