11:05:09 #startmeeting Mer release management meeting 26/6/2012 11:05:09 Meeting started Tue Jun 26 11:05:09 2012 UTC. The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 11:05:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 11:05:33 #info Next release will appear during today 11:06:08 #info Next release: new rpmlint, device-mapper, e2fsprogs, ppl/poppler, libxcb - work towards systemd 185 11:06:15 #info (i mean Next-next) 11:07:01 i think we will have compiler upgrade (further linaro release), rpm upgrade, in due time as well 11:07:07 but not sure it will go in next-next 11:07:37 and next-next: ccache as well 11:07:41 anybody has any high-priority things that we ought to put in? 11:08:00 I think rpm with skip-* should go in -next 11:08:10 :nod: 11:08:13 4.10 with ~ maybe not 11:08:56 i propose next-next on 1207 ? 11:09:22 ok 11:09:31 quite soon IMO but ok. 11:09:37 it's actually like 3 weeks 11:09:37 err... nm :D 11:09:37 :P 11:09:44 * Sage_ was readin 0707 :) 11:09:58 * Sage_ agrees :) 11:10:06 #info start using copyprj as well as part of this, so not too much invasive stuff 11:10:09 I did that ... then thought Saturday? 11:10:21 * Sage_ ponders if he submitted glib2 update already 11:10:28 as long as it's not 1407, i'm okay, that's my birthday.. 11:10:29 :P 11:10:33 systemd ? 11:11:09 systemd is stuff that ought to be done now instead of too late 11:11:11 I have couple of CVE fixes and glib2 fix planned for that 1207 release if I have time to finish those. 11:11:11 imho 11:11:15 udev, systemd merge, etc 11:11:50 there is possible regression for nemo in systemd/udev update that needs to be checked carefully 11:12:03 IIRC x86 adaptation didn't boot or something like that 11:12:05 :nod: 11:12:13 systemd and udev is one thing now 11:12:17 was quite a while ago too 11:12:20 :nod: 11:13:40 phaeron1: could you report on copyprj? 11:14:36 i participated in qt contributor summit over the weekend, qt5 seems to go on 11:16:25 how is Qt looking for next few releases? 11:16:45 we're at Qt5 ... beta1? now 11:16:51 fairly good.. we might have a qt4.8.2 i think, and we're at qt5 alpha 11:16:54 beta1 isn't tagged yet 11:17:01 and for beta1 to be included, we need gcc upgrade 11:17:04 as there was a compiler error 11:17:07 which later linaro fixed 11:17:16 OK 11:17:28 anything we need to get upstreamed wrt Qt ? 11:17:50 4.8.3 will be released in the next few months 11:17:53 i think we're okay regarding to qt patches, bostik handles that issue 11:17:54 s 11:18:46 so what is Qt5 schedule? (roughly) 11:19:32 (just to include this in #info and Mer scheduling) 11:19:37 sorry there was internet issues here 11:19:40 it's a bit of an unknown atm :) 11:19:46 but from what i see, a lot works already 11:20:27 are we looking at July or December for a final release though 11:20:41 the target is august 11:20:53 thanks 11:20:54 how reliable that target is in light of recent events is still not quite clear 11:20:59 yep, understood 11:21:02 but things are generally in good shape 11:21:05 (imho) 11:21:58 so copyprj 11:22:20 is in good enough shape to package and test the new mer process. 11:23:05 it can also help with saving time when one wants to copy a full project state without rebuilding 11:23:20 hello is this thing on :D 11:23:56 yes 11:23:59 ok .. 11:24:35 so what needs to be done next , is create packages in community obs and deploy them to (ci?) and start testing 11:24:55 oh and merge the copyprj branch first 11:25:51 good enough shape means I fixed all known scenarios I could test. 11:26:03 OK 11:26:14 this is based on 2.3.1 too 11:26:27 and we'll want to upgrade C.OBS 11:27:08 so it sounds like a fair bit of ops work to get it deployed 11:27:30 yes I am not sure where to deploy first 11:27:35 and the backup policy 11:27:40 yeah 11:27:59 how about the non-working mer c.obs 11:29:59 so that needs scheduling 11:30:04 let's make sure we can rollback 11:30:21 Stskeeps: you mention doing that this release cycle? 11:32:38 yes 11:32:47 we have 3 weeks of calm ish so 11:33:08 OK 11:33:48 ok 11:34:02 probably announce read only periods over weekend 11:34:22 from my side... I'm working on 'quickbuild' in the SDK 11:34:43 essentially allowing 'make-like' behaviour of osc build 11:35:29 ie ... changing a line of code results in a single(ish) gcc, link operation and then new rpm creation 11:35:54 :nod: 11:36:02 As part of that I got back into the git/pristine-tar work 11:36:34 cool and then we can have the rpms always served from inside the sdk using a yum / zypper repo so devices / vms can pull the new rpm 11:36:36 it would be nice since we want to be working on a source tree and an osc project together--ish 11:36:41 yes 11:37:14 ok I gtg eat now 11:37:28 I am working on our rpm git repo and would like to push it to mer's git 11:37:43 obviously that needs some careful reviewing first 11:38:05 so this is more "heads up, I'll be asking" :) 11:38:54 we'll have one git clone-able repo that has upstream git, pristine-tar, mer packaging and the nasty-mer-packaging trees in it 11:39:48 later on we should be able to remove various refs and do gc to clean up the nasty blobs (and possibly lose some history) 11:39:58 but that's a maybe 11:40:09 yes, tools first 11:40:14 anyhow ... quickbuild first 11:40:30 Then .... package numbering 11:40:50 once copyprj OBS is deployed can we tackle that 11:40:57 yep 11:41:27 ta - would be good to do before our downstreams get too far ahead 11:43:10 minor thing: m2crypto - going to try a rename to python-M2Crypto as part of the update 11:43:42 Had no feedback on SDK 6.0.1 yet - I'll be doing a 6.0.2 soon 11:44:45 We have 2 new servers which I have a plan for doing some migrations to to make use of their increased build speed 11:45:06 that's it from me 11:45:23 :nod: 11:45:25 I should have info'ed some of that :/ 11:45:35 i'm finally back after my journeys, so i can start working again :P 11:45:59 lbt: i'm using 6.0.1 atm. and no issues so far 11:46:10 Sage_: good - ta 11:46:16 used after you told the upgrade cmd :D 11:46:29 I just did zypper ref;zypper up and wondered why didn't I get latest version :) 11:49:06 Sage_: any thoughts on your side about stuff that should be done sooner rather than later 11:49:38 ie potentially disruptive changes 11:50:16 systemd is one that Stskeeps mentioned already. There is some issues in shutdown which might be related to that. 11:50:31 at times shutdown takes very long time or doesn't happen at all on nemo at least. 11:51:35 ok 11:52:00 otherwise it should be just generic updates mainly that I have in my mind. 11:53:11 ah, and busybox would be nice. 11:53:26 famous last words.. 11:53:27 :P 11:53:31 :) 11:53:53 there are some things like tar in sdk that doesn't support some features because we can't update it (gplv3) 11:54:20 busybox should allow those updates as then busybox would be the one that would go to the device, right? 11:54:25 right 11:54:26 yes 11:56:05 oh 11:56:17 next meeting, can we discuss "createrelease.sh" 11:56:27 yours or mine? 11:56:27 :P 11:56:36 do I have to answer that? 11:56:41 yess 11:56:41 :p 11:56:43 :P 11:56:52 * lbt is considering banning Stskeeps from shell coding 11:56:59 * Stskeeps ducks 11:57:06 *g* 11:57:16 really more about what it should be doing 11:57:30 naming conventions and stuff for release directories 11:57:32 goal is to deliver something that can be imported into an MDS, and mic run against repos 11:57:57 I think so too - 2 types of release: normal repos and MDS targets 11:58:17 most of this is probably obvious - we're looking for Mer-related exceptions 11:58:45 so just to raise this as an agenda item for next time 11:58:58 ok 11:59:36 also, to be clear, not just Mer releases, Nemo, Tools, SDK and any other vendor 12:00:45 #info Next meeting we'll discuss what we need/use to make 'releases' of Mer and Vendor projects built on Mer : eg Nemo, Tools/SDK, etc. 12:00:46 :nod: 12:00:51 next meeting same time next week then 12:00:55 yep 12:00:57 food now 12:01:03 thank you all for coming 12:01:04 ty 12:01:04 #endmeeting