17:05:56 #startmeeting Fedora Release Engineering 17:05:57 Meeting started Fri Apr 16 17:05:56 2010 UTC. The chair is Oxf13. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:05:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:06:02 #meetingname fedora-releng 17:06:02 The meeting name has been set to 'fedora-releng' 17:06:09 #topic roll call 17:06:20 /join #fedora-noc 17:06:41 ping: notting jwb lmacken poelcat rdieter dgilmore wwoods (and anybody else) 17:06:45 * notting is here 17:06:50 yo 17:07:33 * dgilmore is here 17:08:36 alright 17:08:53 #info notting rdieter dgilmore and Oxf13 in attendance 17:09:00 (and smooge is running away) 17:09:11 #topic Beta! 17:09:27 Beta got released, although it appears that even after careful checking, I fucked something up. 17:09:42 :( 17:09:43 #info i386 CDs and DVD torrents do not have signed CHECKSUM file 17:09:51 somehow they wound up with the unsigned one 17:10:39 at least thats fairly minor 17:10:50 yeah, the signed one can be grabbed from the web 17:11:05 I hesitated to regenerate the torrent because that would knock off the seeders and it would reset the stats 17:11:08 Oxf13, is that something you need me to look at also with permissions? 17:11:19 smooge: you wouldn't have been able to see it 17:11:24 ah ok 17:11:28 smooge: I just need to pay more attention really 17:12:04 So the question is, is this bad enough to regenerate the torrents and lose the metrics, or do we just let it slide and post a note about it on the common bugs? 17:12:20 i think its ok to slide 17:12:25 * notting is ok with sliding on it 17:12:36 if it were a final release id say redo it 17:12:45 ok, I am too, so I think that's a passing vote. 17:12:45 but beta i think we document and move on 17:13:01 #agreed OK to let torrent have unsigned CHECKSUM, but document it with common bugs 17:13:10 #action Oxf13 to get it documented on common bugs. 17:14:11 I've got nothing else on beta, any of you ? 17:14:38 not beta specifically, no 17:15:06 no 17:16:17 ok, moving on 17:16:25 #topic Duplicate Updates 17:16:36 notting: would you be so kind as to relay what's going on here? 17:17:00 so, we had two issues in F13 recently where 'older' builds ended up in the branched tree because multiple updates were in flight at once, receiving karma, etc 17:17:03 one was with gdm 17:17:07 the other was with libvirt 17:17:24 so i decided today to check how many cases of 'multiple updates in testing for a package' we have. it's over 40 17:17:47 i'm going through and cleaning these up now, will probably take a good chunk of the day 17:18:05 Luke said he was ready to turn the obsolete code back on 17:18:16 #info we have many duplicate updates for F13. this can cause problems 17:18:23 however it won't help in the case of an update being by itself, and a newer version of the package being grouped with another update set 17:18:26 #info notting is attempting to clean this up 17:18:37 it'll only catch things that have the exact same package set, just different versions 17:18:49 Oxf13: that's most of them. if we can turn that on, that would be great 17:18:52 #info lmacken to re-enable obsolete code soon, but still won't catch everything. 17:20:09 ok, I have nothing else on this. 17:20:27 #topic Oxf13 Schedule 17:20:41 I'm going to be spending most of next week preparing for Linux Fest Northwest 17:20:50 I've got two talks to give and prepare for 17:21:01 and since it's a relatively quiet week this shouldn't be a problem 17:21:11 but I won't be monitoring the releng queue much 17:21:23 #info Oxf13 will be preparing for Linux Fest Northwest all week 17:21:42 and I'll be out of the office part of Friday to travel 17:22:07 that's all I have to say about that. 17:22:13 #topic open floor 17:22:18 any other topics? 17:23:12 i'm moderately concerned about the # of f13 updates that don't seem to be progressing. but that's probably more of a fesco issue 17:24:20 is it any more/less than the amount of updates for any other release? 17:24:25 There might be maintainer confusion about what needs to happen for an update to land in branched/final 17:24:38 since the update hits branched once it hits testing 17:24:48 uerm 17:25:03 the update hits updates-testing when it goes testing 17:25:10 but it doesn't get into the nightly branched tree until it goes stable 17:25:19 Oxf13: there are currently more test updates for f13 than for f12 or f11, yes 17:25:34 notting: yeah, I'd expect that. 17:25:40 right, but from the user POV the packages appear on an 'F13' system as soon as they hit 'testing' 17:25:50 wwoods: ah, yes if they have updates-testing enabled. 17:25:58 which is the default configuration for F13 17:26:12 notting: I guess the real question is are there high impact bugfixes we're missing out on because they're stuck in updates-testing 17:26:21 (F13 branched, which is the only extant F13 tree) 17:26:25 or are we succeeding in slowing down the bullshit and keeping branched more stable. 17:28:00 probably about half and half 17:28:12 * notting would encourage everyone to try fedora-easy-karma :) 17:28:55 yeah, I slacked on that due to getting beta out, I'll update and start karma dancing 17:29:28 #info concerned about the number of things in f13 updates-testing 17:29:50 #info guessing at a mix of high value updates being delayed vs low value updates being held at bay 17:30:05 #info need to get back into the swing of fedora-easy-karma on a regular basis 17:31:25 anything else on this topic? 17:31:30 or anything else in general? 17:34:00 I'll take that as a no, thanks all! 17:34:02 #endmeeting