11:06:17 <lbt> #startmeeting Mer Release Management 1 May 2012
11:06:17 <MerBot> Meeting started Tue May  1 11:06:17 2012 UTC.  The chair is lbt. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
11:06:17 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:06:55 <Stskeeps> o/
11:07:18 <lbt> Good afternoon all
11:07:48 <Stskeeps> release work is good so far, we've merged qtbase 5.0.0-alpha1
11:07:56 <Stskeeps> python2.7 caused a rpmlint regression
11:08:18 <Stskeeps> rpmlint-mini, that is
11:10:29 <lbt> and we were notified of a bug in our generic x86 build too
11:10:53 <Stskeeps> yup, i486 was actually i686
11:10:56 <Stskeeps> massive rebuild on the way
11:11:02 <Stskeeps> not ssse3 though
11:11:45 <Stskeeps> we can probably anticipate a slow week next week, as many of us are going to tizen conference
11:11:58 <lbt> so once the rebuild is done I'll push another snapshot
11:12:04 <Stskeeps> lbt: when did we agree on next release?
11:12:09 <lbt> 17 May
11:12:11 <Stskeeps> ok
11:12:53 <Stskeeps> so, my schedule (well, it was supposed to be) is working on sb2-obs v2 this week
11:12:56 <Stskeeps> of course things get in the way
11:13:01 <Stskeeps> how about the rest of you?
11:13:08 <lbt> I'm on OBS
11:13:18 <Stskeeps> also, kudos to the obs-setup scripts
11:13:33 <Stskeeps> they need a little documentation on the .conf format, but otherwise worked perfectly
11:13:45 <lbt> pushed a few mins ago :)
11:14:03 <Stskeeps> what specificaly about OBS?
11:14:06 <lbt> they're helpful - takes ~4mins to do an OBS deploy and MDS test
11:14:16 <lbt> so now I need to validate copyproject
11:14:27 <lbt> which is included in our mer_patches branch
11:14:49 <lbt> phaeron wrote that ages ago and I understand it
11:14:55 <lbt> but not how we plan to use it
11:15:05 <Stskeeps> from a usecase pov, we need to verify we can do this:
11:15:25 <Stskeeps> http://wiki.merproject.org/wiki/Process#New_process_2
11:15:45 <Stskeeps> basically, move <link from one project to another past-copy, and see that it works
11:16:17 <lbt> hmm
11:17:48 <lbt> so just want to check what benefit
11:17:57 <lbt> mainly image building?
11:18:40 <lbt> slight concern over disk space issues too
11:19:18 <Stskeeps> remember our discussion about full releases
11:19:39 <Stskeeps> the idea is to be able to take a given release build, do a modification, build the changed release build
11:20:08 <Stskeeps> and do a full snapshot for image builds and reproducability of this
11:20:23 <lbt> and these are DBC builds
11:20:48 <Stskeeps> they can be, but also integration builds
11:21:24 <Sage__> hi, sry I'm late
11:21:28 <lbt> the word "release" means (to me) something we publish to the world as a somehow useable snapshot
11:22:02 <Stskeeps> ok, can we get back to the technical part, i'll just briefly paint out why i need this specific operation
11:22:06 <lbt> once it has been checked, a DBC build could be renamed as a release
11:22:16 <lbt> yeah - I just want to check where we are
11:22:24 <lbt> gerrit mode or weekly snapshot time
11:22:43 <lbt> release means weekly snapshot but I care more about gerrit :)
11:24:39 <Stskeeps> lost my mind train.. moment
11:25:15 <Stskeeps> ok, so, terms: 'a build' means a full compilation of the sources that we have into RPMs. to check if a change breaks anything, we modify the sources and do a build, run tests on top of that
11:25:19 <Stskeeps> right?
11:25:48 <lbt> OK
11:25:59 <Stskeeps> because distributions can't bootstrap from scratch, we start from a previous build, change sources, do a build, run tests on top of that
11:26:02 <lbt> full = dependency-check-driven
11:26:16 <Stskeeps> ignore that part, i want to talk about builds in general
11:26:29 <Stskeeps> in our case, 'sources' is our OBS project, ie, packages and their attached sources
11:26:56 <Stskeeps> so in practice, when we 'change sources', we add/remove packages, or change the git revision they point to, in the OBS project
11:27:49 <lbt> "Switching <link project=""> to the new project description"   should that say *in* the new project?
11:29:09 <Stskeeps> operation is simple: start from project X with binaries matching sources in OBS project Y, copy project, sources and binaries to project A, and then switch project A to match source in OBS project B'
11:29:19 <Stskeeps> B being Y with our new change
11:29:43 <Stskeeps> so in practice, we end up that project A will have binaries matching sources in OBS project B
11:30:46 <Stskeeps> so we copy project as-is and then change the underlying sources
11:31:30 <Sage__> ..
11:31:39 <Stskeeps> we really need a whiteboard.
11:32:02 <lbt> so my question? ... answer is "yes" ?
11:32:08 <Stskeeps> yes
11:32:35 <lbt> I'm sorry it's such a tiny thing but it inverts what I understood :)
11:33:39 <lbt> I thought you were changing the link in the original to point at the new .... kinda .... wtf?
11:34:13 <lbt> I'll edit wiki
11:34:14 <Stskeeps> example can be to have a build Our:Core:0.2012.1, with <link project="MDS:Core:0.2012.1" />, do a copy to Our:Core:0.2012.2, and then change that one's <link project to point to MDS:Core:0.2012.2
11:34:26 <lbt> oh, yeah - I fully understand now :)
11:34:54 <Stskeeps> so we end up having Our:Core:0.2012.2 matching sources in MDS:Core:0.2012.2
11:34:58 <lbt> main issue to me is the resolver handling a <link> change underneath it
11:35:01 <Stskeeps> yes
11:35:06 <Stskeeps> that's why i want you to verify it :)
11:35:39 <Sage> <link> isn't enough in that is it <repository> also needs the proper lines right?
11:36:19 <Stskeeps> there you could do a linkedbuild="all", but for the sake of explanation that's implied
11:36:35 <Sage> ok
11:37:16 <Stskeeps> this method could hence also be used in other CI-using projects
11:37:32 <lbt> it's very expensive on disk space
11:38:00 <lbt> but I found http://linux.die.net/man/1/hardlink
11:38:06 <Stskeeps> it is, but i'm not expecting everything to be retained
11:38:20 <lbt> I'm highly tempted to use ln
11:38:23 <lbt> not cp
11:38:37 * lbt looks at Islam's patch
11:38:39 <Stskeeps> as reproduction is easier if we have a standard method
11:38:57 <Sage> wouldn't also some filesystemd do that automatically? btrfs?
11:39:08 <Stskeeps> dedup file systems, yes
11:39:24 <Stskeeps> but in practice, the advantage may on average not be a lot
11:40:33 <Stskeeps> but for some things..
11:40:34 <Stskeeps> maybe
11:40:35 <Stskeeps> either way
11:40:45 <lbt> optimisation :)
11:40:53 <Stskeeps> we need to check this works as it enables proper branching and QA
11:41:09 <Stskeeps> and release branch management/releases
11:41:10 <lbt> I think we may need project rename too
11:41:19 <Stskeeps> maybe
11:41:24 <Stskeeps> let's check this one first
11:41:30 <Stskeeps> you can probably do Core and Core-next as an example
11:42:16 <lbt> I'm OK doing basic tests here but anything with serious amounts of data is really slow
11:42:30 <lbt> I may see about getting a new phost setup
11:43:58 <lbt> out of interest...
11:44:26 <lbt> how would this be if a 'publish' went to the link to get binaries
11:44:44 <lbt> normally a publish only pushes the rebuilt rpms
11:44:55 <lbt> so it's sparse in a linked project
11:45:04 <Stskeeps> linked build =all
11:45:25 <lbt> no, not build
11:45:31 <lbt> linkedpublish=all
11:46:37 <Sage> is there linkedpublish?
11:46:41 <lbt> not yet
11:46:52 <Sage> ok, well I missed it already couple of times :)
11:47:06 <lbt> but I'm thinking it may be closer to what we actually want
11:47:37 <lbt> althought then at some point we'd need a "copy-all"
11:48:05 <Stskeeps> let's get basics working first, then optimize
11:48:08 <lbt> mmm copyproject could do that ... have a flag to follow links
11:48:24 <lbt> OK
11:49:27 <lbt> so anyhow... that's an active WIP
11:49:56 <lbt> I'm also thinking about how to do Tools/OBS/MINT promotion/releases too
11:50:16 <lbt> and how we do git branch/patch management
11:50:39 <lbt> (oh, Stskeeps can you verify the sb2 code in merproject mer_patches_2.3 branch)
11:51:03 <lbt> I did a lot of rebasing and think it's all there but...
11:51:13 <Stskeeps> will do, g
11:51:46 <lbt> what else....
11:53:21 <lbt> infra news... our donation policy isn't appropriate for one of our donors so I need to let the AB know this week. Means we're not getting one new server which is a shame.
11:53:42 <lbt> I've setup icinga monitoring
11:53:51 <lbt> which means I know that monster is in critical
11:54:00 <lbt> :/
11:54:50 <lbt> anyone else have anything?
11:55:16 <Stskeeps> lbt: i don't see mer_patches_2.3 branch?
11:55:42 <Sage> I'm doing some package updates for the next release and have some of them in review already
11:55:49 <lbt> https://github.com/Merproject/open-build-service/tree/mer_patches_2.3
11:55:57 <Sage> hitting quite badly to python 2.7 update regression though with rpmlint at least
11:56:16 <Stskeeps> lbt: OK.. 'build' is where the worst should be
11:56:34 <lbt> Stskeeps: not done anything there recently
11:56:43 <Stskeeps> ok
11:56:59 <lbt> Sage: are you working on that or do you need help
11:57:13 <Stskeeps> i've fixed the rpmlint issue, i hope
11:57:15 <Stskeeps> will know later today
11:57:16 <Sage> I'm not working on that python issue. Help would be appreciated
11:57:21 <Sage> Stskeeps: ah nice
11:57:37 <Stskeeps> it was a rare-ish case it hit
11:57:48 <lbt> I think we need a notification to #mer with gerrit requests
11:57:50 <Stskeeps> ie, a 'import logging' inside an except: ..
11:57:53 <lbt> I'd glance at them
11:58:00 <Stskeeps> reviews yes, messages no
11:58:03 <Stskeeps> would be too spammy
11:58:12 <Stskeeps> ie, when a new changeset comes in is ok..
11:58:22 <lbt> start and reject/accept ?
11:58:54 <lbt> anyhow... just musing :)
11:59:09 <Stskeeps> alright, anything else?
12:00:10 <lbt> futures
12:00:19 <Stskeeps> futures?
12:00:40 <lbt> I'm hoping to use the CI/BOSS work to drive the versioning / policy work
12:00:50 <Stskeeps> :nod:
12:00:53 <Stskeeps> i agree
12:00:58 <lbt> so that's possibly disruptive
12:01:24 <lbt> I don't think vendors will be affected much
12:01:37 <lbt> but I'll know more as I get into it
12:02:05 <Stskeeps> well, there's always the MDS2 impact as well of it
12:02:13 <Stskeeps> but that should be a benefit more than disadvantage
12:02:17 <Stskeeps> fixing many of the delivery problems we have
12:02:24 <Stskeeps> and ability to do local forks of mer
12:02:47 <lbt> yep
12:03:03 <lbt> any outline of changes yet?
12:03:21 <Stskeeps> hm?
12:03:34 <lbt> brainfade - I read SB2
12:03:47 <lbt> and then thought ... forks?
12:04:53 <lbt> I do feel the need to hack a lot at our release code though :)
12:05:04 <lbt> it needs to be more robust
12:05:38 <lbt> The pristine-tar git stuff is getting to me aswell - cairo has 60Mb blobs in .git ... not good
12:05:48 <lbt> but that's it from me afair
12:06:27 <Stskeeps> :nod:
12:06:46 <Stskeeps> i'd like you to maintain MDS2 too, if possible
12:06:50 <Stskeeps> as it's very tied to vendor delivery
12:07:02 <lbt> OK
12:07:16 <Stskeeps> we can do a knowledge transfer while in SF perhaps
12:07:24 <Stskeeps> and walk through the code
12:07:46 <lbt> yeah - we should make a list of things to do in front of a wb
12:08:09 <lbt> it looks like they've kindly given us *lots* of free time :)
12:11:05 <lbt> are we done then?
12:11:10 <Stskeeps> yep
12:11:28 <lbt> ty all for coming ....
12:11:31 <lbt> #endmeeting