12:00:54 #startmeeting Mer release management meeting 12:00:54 Meeting started Tue Feb 28 12:00:54 2012 UTC. The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 12:00:54 Useful Commands: #action #agreed #help #info #idea #link #topic. 12:02:05 we have a release out! 12:02:10 \o/ 12:02:43 and of course we botched a couple of things along the way :) it turned out that MDS did not send updates about prjconf / meta changes 12:02:44 * lbt wonders what an audio pickup near Stskeeps would have heard as he walked lbt through the process... 12:02:57 #link http://www.mail-archive.com/mer-general@lists.merproject.org/msg00304.html 12:04:32 what other experiences did we have? 12:04:33 I'll be documenting that sometime soon 12:04:36 MDS needs to be more intelligent 12:05:11 One issue was hacking on the live box is more problematic when >1 person is administering 12:05:27 "no, that hack is OK, I meant to revert the other one" :D 12:05:45 (just as a lesson learned) 12:05:47 yes, someone managed to wipe out the MDS mappings.xml for community obs, as well 12:05:53 moi? 12:05:56 hence the MDS needs to be more intelligent, as we're too stupid 12:06:24 This fits into the MDS rewrite/upgrade anyway 12:06:28 :nod: 12:06:43 i was planning to work on MDS more but this will come soon 12:06:48 anyhow - teaching and therefore mission acomplished ... 12:06:58 the upstreaming of SB2-OBS is taking a different patch direction due to two-three concurrent cross proposals 12:07:09 so there might be follow up patches to it 12:07:25 I saw the sysroot thing but didn't follow through 12:07:45 this will also be needed for the toolchain-core split 12:07:55 yeah - that was my next question 12:07:55 as seen in the B2G devices, there is some merit to this kind of stuff 12:08:09 does it affect that design we worked up ? 12:08:12 or is it aligned? 12:08:38 we might be able to do a saner design, without aggregates 12:08:46 it remains to be seen 12:08:49 OK 12:09:15 It doesn't feel like it will affect the SB2 SDK work 12:09:19 mm 12:09:19 sry I'm late 12:09:34 +1 \o/ for the release 12:09:59 I should say, I did a fair bit of rework on the SDK script - not a lot to show but I think it's a saner approach 12:10:24 I have had very little feedback which is dissapointing 12:10:32 just means people are happy ;) 12:10:33 or maybe it works 12:10:55 so they are happy? :) 12:10:57 will you do a release matching the new release? 12:11:00 so I'll do a new SDK image 12:11:06 now we have a new release :) 12:11:18 :nod: 12:11:24 Then we need an i486 version of cross tools 12:11:26 that's a biggy 12:11:28 right 12:11:36 how intrusive is that? 12:11:37 that comes after the next build 12:11:39 lbt: ping me when it's ready. I'll try it after I get home (in an hour or so) 12:11:42 not very intrusive 12:11:45 timoph: OK 12:11:53 just not a thing i wanted to do at end of release cylcle 12:11:59 of course 12:12:20 I'd really like to get the SB2 into the SDK and try to find ways to make it more holistic 12:12:33 :nod: 12:12:39 that's one of the aims for this week wasn't it 12:12:43 yes 12:12:45 yes 12:13:08 also, I know it's caused some disquiet - but I think lxc may be a better solution than chroot for us 12:13:40 it's actually just a spiritual successor to how chroot is used for isolation 12:13:49 not totally against, but we have to weigh ease of installation vs idiot-proofing 12:13:51 so let me work on it and see how it goes 12:13:58 i don't want to end up with sb1 again 12:14:08 back from dr. appointment 12:14:31 yep - I am 99% sure it will have a simple dependency against the lxc binary - almost identical to using qemu 12:15:19 and in the script I expect to s/chroot /lxc / 12:15:20 jumping in, so my reservation against lxc after trying it a lot before , is that it is missing some separation / virtualization 12:15:32 what happens if you run 'halt' in lxc? 12:15:39 yeah, it's a replacement for chroot 12:15:43 not VM 12:15:51 Stskeeps: what happens if you run it in a chroot? 12:16:04 well, monster.tspre.org goes down 12:16:06 :P 12:16:13 true story 12:16:13 don't do that then :) 12:16:20 haha 12:16:35 so, assuming we have a next release in a week, what's realistic goals? 12:16:44 i'd like to get llvmpipe in, at least and mesa 8.0 12:17:05 not Qt5 12:17:17 as well as merging gdb, zip 12:17:21 that may go alpha in a week+1 though 12:17:24 :nod: 12:17:36 python2.7 -- too risky? 12:17:41 * lbt wonders if we should aim low 12:17:45 ok 12:17:49 so a bog standard release 12:17:57 and introduce some new processes 12:18:01 or refine existing 12:18:06 lbt: systemd inside lxc can break the host sometimes btw 12:18:07 :nod: 12:18:07 eg release blocking bugs 12:18:12 Stskeeps: I would hold python 2.7 back one release at least 12:18:20 ok 12:18:31 Stskeeps: the pcre is already there so we might have enough problems with that one :) 12:18:32 anyway for another discussion 12:18:40 phaeron: as it would inside chroot - but lets take this to #mer post meeting? 12:18:41 please review D Wadsworth's patches, they pass DBC/SBC, but i wouldn't mind a deep package review 12:18:56 Stskeeps: are they python? 12:19:02 Stskeeps: also I would like to see udev and systemd updates in next release 12:19:08 that should be possible 12:19:21 so maybe an "upstream sync" release? 12:19:30 i think that's enough content, with MDS aligned as well 12:20:07 so... thoughts on making some decisions (goals) and making release-blocker bugs? 12:20:24 as a way to track progress towards a release 12:20:48 also we should really do zypper update in some of the upcoming releases as well. 12:20:52 yes 12:21:07 lbt: should be integrated with our BOSS/CI process 12:21:31 question: when the next release is due? This friday? 12:21:33 agreed - but it should also be worked through manually before we automate it 12:21:43 Sage_: i think from today + week 12:21:58 the schedule for releases is foobar at the moment 12:22:20 :nod: also I think release every week is a bit too tight schedule. 12:22:29 14 day schedule maybe? 12:22:35 considering we always ship 'stable' 12:22:44 that sounds better IMO 12:22:45 seems better to me 12:22:47 ok 12:22:51 well, less headache for me then 12:22:55 #info 14 day release schedule 12:23:06 so +1w and +3w ? 12:23:07 so far we have had too much rush with the releases 12:23:19 lbt: think so 12:23:25 lbt: ? 12:23:32 err.. 12:23:44 +2w and +4w you mean? 12:23:54 Sage_: just checking if this 14 day overrides release in +1w as we just said 12:24:17 +2w, +4w I would say 12:24:33 with some prereleases inbetween 12:24:42 :nod: 12:24:48 just noting we made all the decisions based on the next release assuming +1w 12:25:15 so ... does more go in or do we just have more breathing space? 12:25:26 since I said Qt5 alpha goes in in 2w 12:25:39 yes, that'd be in next-next 12:25:49 in 4w ? 12:25:52 qt5 in +4w 12:26:12 yeah, merged into the release that opens in 2w 12:26:17 so we can do prereleases, etc 12:26:21 as the packaging isn't ready yet and not submitted even review 12:26:27 #info qt5 in +4w release 12:26:45 setting a goal == release blocker :) 12:26:50 :nod: 12:27:01 python2.7 in 4w? 12:27:09 make sense 12:27:11 :nod: 12:27:21 #info python2.7 in +4w release 12:27:34 * Sage_ is guessing that python 2.7 will cause some work for vendors 12:27:46 * lbt looks at sdk too 12:28:06 and mcrypto package name 12:28:08 grrr 12:28:10 will a sb2 'sdk' in +2w make sense? 12:28:23 I would like that 12:28:25 if you get prereleases early of _i486 switchover 12:28:26 if not sooner 12:28:55 yes 12:29:46 So phaeron has done some work on IMG and mic 12:30:01 *blush* 12:30:04 :D 12:30:05 and we can start to use that once we have this new deployment done 12:30:16 which will really help on the BOSS/CI 12:30:20 :nod: 12:30:32 I'd like to make adding rootfs builds the first delta 12:30:40 i'd like to not be too involved in CI implementation, except for stating requirements from architect pov 12:30:43 if possible 12:30:54 phaeron: can you take action to upload project-copy patches? 12:30:54 yes - that's the idea, we de-hack it 12:30:58 * lbt ducks and runs 12:31:22 Stskeeps: yes will do that , wil create a bug to track it 12:31:31 * Sage_ likes the humoristic touch in the conversation ;) 12:31:32 (oh, then the MIPS builds once we've gotten some feel for it) 12:31:49 Sage_: good, you're still evil. 12:32:07 * lbt has an aspiration to have a review accepted 1st time! 12:32:10 instead of having a monolithic Core:i586 / armv7l tree, i'd like to move the idea of copying a previous release and making a new one by copy 12:32:23 this will take more space on CI, but make more sense from BOSS/CI proces 12:32:41 s 12:32:47 I'd like to clean up what we have before moving on to things like that 12:32:51 Stskeeps: /me still doesn't get 12:32:59 there's a lot of partially production-ready ideas 12:33:00 but I am sure the patches will help 12:33:05 okay 12:33:06 well 12:33:17 lbt: hehe :) 12:33:34 toolchain split is still ongoing 12:33:49 so maybe queue the copyrelease behind that 12:34:26 Stskeeps: if you want stuff to do .... removing tspre from all our docs/scripts would also be good 12:34:43 (it can get confusing to vendors I think) 12:35:02 and I'm not sure exactly what's going on with all the names :) 12:35:26 reminder http://airy:5001 is the internal wiki for infra 12:35:38 agreed 12:35:47 the idea is to not use tspre.org and eventually wiping monster 12:35:53 *nod* 12:36:20 copyrelease has to be done before toolchain split, we can't ensure a sane CI process at the moment without 12:36:31 for various reasons 12:36:34 ah - didn't know that dependency 12:36:52 i have to do too much manual work atm 12:37:04 and we need to be able to do full-repo snapshots with CI, for IMG tests 12:37:05 http://wiki.merproject.org/wiki/Process#New_process_2 12:37:11 yep 12:37:17 dep checks are localdep atm 12:38:04 OK - so does i486 cross come first? 12:38:11 yes] 12:38:20 and you asked about making i586 a target 12:38:22 I think yes 12:38:40 huh/ 12:38:42 ? 12:39:05 ages ago you asked if i586 should be a cross-target I think 12:39:09 ah yes 12:39:20 tha's toolchain-core split stuff 12:39:29 I don't know - I would like to build Atom code on my AMD desktop 12:39:46 OK - I mention it just in case it was cross related 12:41:00 (pizza came in the door, oment..) 12:41:26 priorites: i486 cross for SB2 for SDK; copy-release for OBS; toolchain split ?? 12:41:52 toolchain split needs the sb2 rebase stuff first 12:41:58 so design phases first 12:42:17 priorites: i486 cross for SB2 for SDK; copy-release for OBS; sb2 rebase; toolchain split ?? 12:42:38 copy-release -and- automated BOSS/CI tests/img 12:42:54 I have them in a different dependency list :) 12:42:56 does the sb2 rebase impact the SDK SB2 work ? 12:43:00 no 12:43:02 IMG working for rootfs (nested stuff); BOSS CI process 12:43:03 *head spin* 12:43:15 Stskeeps: good 12:43:21 phaeron: mm? 12:43:39 too many acronyms on one line 12:43:45 never mind me 12:44:43 lbt: one last warning, not fud, I did get a physical host hard freeze with nested kvm on my laptop. did you try it at on some machine on your side ? 12:45:00 phaeron: we will 12:45:12 ok 12:46:05 OK .. so here are 4 threads of work 12:46:14 i486 cross for SB2 for SDK; copy-release for OBS; sb2 rebase; toolchain split 12:46:15 IMG working for rootfs (nested stuff); BOSS CI process (rootfs build and MIPS) 12:46:17 MDS rewrite and release processes 12:46:18 Infra: tspre name, LDAP on IMG, C.OBS https mess 12:47:11 * lbt checks backlog for missing bits 12:47:35 SDK SB2 12:48:34 anything missed? 12:48:56 makes sense for RM work 12:49:07 toolchain split is 'design phase and experimentation' 12:49:39 sb2 rebase and MDS rewrite (at least basics) is on me 12:49:41 any other OBS ? 12:49:58 we need guides on how to deploy merproject OBS and tools 12:50:12 slaine would be good as he's setting up one now 12:50:14 I should work that through with slaine today 12:50:17 yes 12:50:18 hehe 12:50:25 I'll info them for now then 12:50:33 #info threads of work 12:50:34 #info i486 cross for SB2 for SDK; copy-release for OBS; sb2 rebase; toolchain split design phase and experimentation 12:50:36 #info SDK on new release and SB2 integration 12:50:37 #info IMG working for rootfs (nested stuff); BOSS CI process (rootfs build and MIPS) 12:50:39 #info MDS rewrite and release processes 12:50:40 #info Infra: tspre name, LDAP on IMG, C.OBS https mess 12:50:49 o_0 12:50:54 mm? 12:50:56 * Sage_ has same feeling phaeron had :) 12:51:02 yeah.. 12:51:06 we need wiki/Dictionary 12:51:08 I know... 12:51:22 We do need dictionary to wiki.. 12:51:46 #info TLA dictionary: http://wiki.merproject.org/wiki/Category:About 12:52:15 Sage_ and Stskeeps thanks for volunteering to add some terms in there 12:52:29 #action Sage_ and Stskeeps thanks for volunteering to add some terms in there :D 12:52:36 do you have a page on how to add terms to the categories page ? 12:52:38 :D 12:52:43 :P 12:52:44 he who invents the TLA writes the page 12:52:46 http://wiki.merproject.org/wiki/About_category_guidelines 12:52:53 damn 12:52:53 :P :P :P 12:53:19 * lbt enjoyed that so much ... you can ask again 12:53:56 lbt: you'll action on documentation for the hordes of people needing new 'osc' and 'build' for ARM SB2 builds? 12:54:03 as part of sdk/tools 12:54:07 yeah 12:54:09 k 12:54:21 partly why I'm in a rush on SB2 12:54:29 I don't want to document it twice 12:54:37 mmm 12:54:49 osc and build are using sb2 transparently, but ok 12:54:49 I don't know how things might change 12:54:57 osc build is, yes 12:55:01 we need to make sure Mer:Tools:Testing has merproject osc and build 12:55:11 *nod* 12:55:22 upgrade OBS ? 12:55:28 is that RE or infra ? 12:55:38 both, i guess 12:55:50 partly BAU 12:55:58 I do wonder if we need an infra meeting 12:55:59 I already pushed updated rpms 12:56:06 it sometimes feels OT in here 12:56:16 BAU? 12:56:22 business as usual 12:56:39 maybe we should make infra phase 2 of RE? they are tightly related 12:56:57 * lbt looks at "Sage_ the worker killer" 12:57:36 maybe do that next week ? 12:57:44 before next week 12:57:48 we really need search button to work 12:57:48 * Sage_ ponders where is lbt's next review ;) 12:57:56 Stskeeps: +1 12:58:13 oh, that's ASAP 12:58:40 I meant shall we have an infra section at the end of next weeks RE meeeting or as a followon 12:58:48 ah 12:58:59 i think it's just part of RM 12:59:04 for now 12:59:13 OK - fine by me - I won't be shy about it then 12:59:13 it all serves to make a good release, so 12:59:25 though i think we should wrap up now 12:59:35 no need to separate things as long as thing go nicely forward. 12:59:40 *nod* 12:59:46 I've not done anything about getting a new machine from vgrade 12:59:53 if we things start to mix up then we can think about doing different topics 12:59:57 slightly nervous about scaling up the infra 13:00:08 we'll need to make some decisions soon 13:00:09 any reasons for this? 13:00:18 let's take those in #mer ? 13:00:24 OK 13:00:28 thank you all for coming 13:00:33 cya 13:00:37 #endmeeting