17:36:45 <Oxf13> #startmeeting Release Engineering
17:36:45 <zodbot> Meeting started Fri Mar 26 17:36:45 2010 UTC.  The chair is Oxf13. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:36:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:36:52 <Oxf13> #meetingname fedora-releng
17:36:53 <zodbot> The meeting name has been set to 'fedora-releng'
17:36:57 <Oxf13> #topic roll call
17:37:34 <Oxf13> ping: notting jwb rdieter wwoods lmacken dgilmore poelcat tyll spot
17:37:40 <Oxf13> (and anybody else who wants to join the fun)
17:37:41 * lmacken 
17:37:42 * notting is here
17:37:54 <jwb> have to skip today, sorry
17:39:33 <Oxf13> k should be short
17:39:45 <Oxf13> #info present are lmacken notting oxf13
17:39:48 <Oxf13> #info regrets jwb
17:39:55 <Oxf13> #topic Beta!
17:40:20 <Oxf13> Beta RC1 was posted, but it does have some issues necessitating an RC2.  I have hopes of getting RC2 spun today and tested over the weekend
17:40:45 <Oxf13> https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test and https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test have the test results
17:40:51 <notting> does that still let us hit our schedule?
17:41:06 <Oxf13> yes
17:41:26 <Oxf13> we're not in the "no go" state as of yet
17:42:03 <rdieter> here
17:42:13 <Oxf13> one thing that came up though, was broken deps on the x86_64 DVD, across acrhes
17:42:25 <Oxf13> this happened because I grabbed newer packages but didn't make my side repos multilib
17:42:40 <Oxf13> and I just checked with clumens, and you can't even use kickstart to convince yum to do multilib during installs, it still defaults to "best"
17:42:55 * dgilmore is here
17:42:56 <Oxf13> so I'm kind of wondering why we put all possible multilib packages on the media
17:43:10 <Oxf13> I think we should instead also use "best" methodology when composing the media
17:43:17 <Oxf13> #info rdieter and dgilmore also present
17:43:55 <rdieter> Oxf13: indeed
17:44:22 <dgilmore> Oxf13: id be ok with making install media singlelib
17:44:47 <notting> Oxf13: works for me. how hard would that be?
17:44:52 <Oxf13> little late to do that for Beta, but perhaps with lots of testing between beta and final...
17:45:11 <Oxf13> notting: probably not too hard, just slightly altering pungi's gather selection process
17:45:17 <Oxf13> if it looks too scary, I'll pass for F13
17:45:53 <notting> well
17:46:08 <notting> given our releases and schedule, might as well push to F14 if we don't get it in beta. less surprise for people.
17:46:09 <Oxf13> #info Installs don't do multilib, so why put multilib packages on media?
17:46:23 <Oxf13> #action Oxf13 to look at how difficult it would be to stop doing multilib on media
17:46:37 <Oxf13> notting: surprise, that thing you can't use is no longer there?
17:46:41 <Oxf13> (but i get your point)
17:47:07 <notting> dumb question: new branched trees and updates aren't pushed at the same time, correct?
17:48:59 <Oxf13> right
17:49:06 <Oxf13> one is done via bodhi, one is done via cron
17:51:07 <Oxf13> there are some issues with packages "disappearing" from -testing before they make it to -stable.
17:51:15 <lmacken> is there?
17:51:27 <Oxf13> yah, when it goes "stable" it gets untagged from -testing
17:51:34 <Oxf13> but the cron stable compose might not run for another 12~ hours
17:51:45 <lmacken> oh, I see
17:52:05 <Oxf13> We could get clever here and not do the untag until after it's been mashed
17:52:10 <Oxf13> and have the mash process do the untag
17:52:27 <notting> ugh
17:52:32 <Oxf13> I know
17:52:36 <lmacken> or maybe just have it add-tag, instead of move-tag ?
17:53:10 <Oxf13> lmacken: right, bodhi would just tag-pkg, instead of move-pkg.  But then something else would have to clean up so that we don't have things in both updates-testing /and/ branched
17:53:18 <lmacken> yeah, that would get messy
17:54:43 <Oxf13> anyway, that's all I got for beta.
17:54:47 <Oxf13> #topic Open Floor
17:54:56 <Oxf13> I haven't thought about anything but beta this week, so...
17:56:34 <dgilmore> i have nothing extra
17:56:36 <notting> oh
17:56:51 <notting> we set 'metadata_expire=7d' in our yum repo files
17:56:57 <notting> this seems bad w.r.t. branched?
17:57:12 <notting> skvidal: ^^ ?
17:57:16 <dgilmore> notting: probbaly want 1d for branched
17:57:18 <Oxf13> oh wow, yeah probably
17:57:21 <Oxf13> shit
17:57:26 <Oxf13> so much for re-using the "fedora.repo" file :/
17:57:35 <skvidal> what? yes?
17:57:43 <Oxf13> I really don't want to be making changes to that at the end of the release process :/
17:57:45 <notting> Oxf13: actually, double-check that with a clean package. i may have something old that's still there due to %config
17:57:55 <dgilmore> we probably only want to set that to 7d for final
17:57:58 <Oxf13> notting: no, I'm pretty sure it's 7d
17:58:07 <Oxf13> once released, we assume the "fedora" repo doesn't change
17:58:19 <skvidal> yes it is
17:58:23 <skvidal> yep
17:58:31 <skvidal> it's not w/o good reason
17:58:51 <notting> skvidal: oh, absolutely. it just doesn't DTRT with how we push the branched tree now
17:58:59 <skvidal> nod
17:59:01 <skvidal> agreed
17:59:43 <Oxf13> so....
18:00:02 <Oxf13> instead of using fedora.repo to get you branched stuff, we could use fedora-updates.repo
18:00:57 <notting> Oxf13: we *could*... but that's a lot of extra stuff just sitting on the mirror not changing. also, loses some of the benefit of hardlinking it over at release time
18:01:09 <Oxf13> say what?
18:01:20 <Oxf13> i wasn't talking about moving the location of the bits, just using a mirrormanager redirect
18:01:42 <notting> oh. so it's just a double metadata download
18:01:44 <Oxf13> it's either that, or we monkey with the feodra.repo contents throughout the release and risk lots of .rpmnew bits
18:02:46 <Oxf13> or introduce a new branched.repo file
18:03:09 <notting> ... have a cron job that expires the metadata for you daily ;)
18:03:17 <Oxf13> ....
18:04:30 <notting> i'm not sure i like the idea of monkeying with a branched.repo file much better.
18:05:27 <Oxf13> there aren't many good options here
18:05:29 <notting> skvidal: does in-repo-file metadata_expire override the yum.conf value?
18:05:39 <skvidal> yes
18:05:44 <skvidal> that is, in fact, the point of them
18:05:48 <notting> true
18:05:49 <skvidal> [main] is global
18:05:52 <skvidal> [repo] is specific
18:06:44 * notting wonders why he was only noticing this with the debuginfo repo
18:08:23 <Oxf13> I think I didn't notice it because I've got a really old fedora.repo I've been carrying around
18:09:39 <notting> hm... just treat this as an open issue until we think of something?
18:09:46 <Oxf13> probably
18:09:51 <notting> ok, i'll put it in trac
18:09:55 <Oxf13> thanks
18:10:43 <Oxf13> anything else or can we call this a wrap?
18:11:29 <notting> what spins are getting pushed for beta?
18:11:29 <dgilmore> wrap her up
18:11:39 <Oxf13> notting: no spins, just official live meida
18:11:40 <Oxf13> media
18:11:49 <Oxf13> spins testing gets done via the nightlys
18:13:48 <Oxf13> alright, thanks all!
18:13:50 <Oxf13> #endmeeting