21:02:12 #startmeeting F16 Beta Go/No-Go Meeting 21:02:12 Meeting started Wed Sep 21 21:02:12 2011 UTC. The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:02:21 #meetingname F16 Beta Go No-Go Meeting 21:02:21 The meeting name has been set to 'f16_beta_go_no-go_meeting' 21:02:28 #topic Gathering Bodies and Minds 21:02:30 who's here? 21:02:32 * nirik waves. 21:02:34 * jsmith is here! 21:02:38 * tflink is present 21:02:41 * athmane around 21:03:09 dgilmore anywhere? 21:03:39 Well, we'll proceed. 21:03:53 #topic Why are we here? 21:04:00 "You know the answer, just as I did" 21:04:05 Oh, that's a movie. 21:04:09 #info The purpose is to decide whether the Final release criteria have been met 21:04:21 #info NO. 21:04:22 #undo 21:04:22 Removing item from minutes: 21:04:23 #undo 21:04:23 Removing item from minutes: 21:04:34 #info The purpose is to decide whether the *beta* release criteria hav ebeen met. 21:04:47 * rbergeron is tired. 21:04:58 * dgilmore will only be here for 10 minutes 21:05:13 #link http://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria 21:05:24 * satellit_ listening 21:05:29 #chair adamw tflink jsmith dgilmore 21:05:29 Current chairs: adamw dgilmore jsmith rbergeron tflink 21:05:46 So. 21:05:48 #chair adamw 21:05:49 Current chairs: adamw dgilmore jsmith rbergeron tflink 21:05:53 let's talk blocker bugs, first. 21:06:02 #topic Remaining Blocker Bugs 21:06:14 #link https://fedoraproject.org/wiki/Current_Release_Blockers 21:06:34 I see three proposed... and at least one in new. 21:06:52 adamw, tflink: this looks obviously no-goish at this point, but can we get some info? 21:06:53 three proposed? 21:06:57 the new one is actually fine 21:07:01 I count 6 21:07:02 it would be fixed in rc2 21:07:13 the big outstanding problem bugs are: 21:07:20 http://bugzilla.redhat.com/show_bug.cgi?id=738803 21:07:27 oh, right, and two in assigned. 21:07:32 http://bugzilla.redhat.com/show_bug.cgi?id=737731 21:07:39 and 2 in assigned in proposed. 21:07:41 and http://bugzilla.redhat.com/show_bug.cgi?id=738964 21:07:47 which should be accepted, not proposed 21:07:59 #info Big outstanding bugs are 738803, 737731, 738964. 21:08:28 Do we want to go through them real quick and move them to accepted blockers? 21:08:29 we have fixes for 738803 and 738964 but they have only landed very recently and we haven't even managed to do a compose with them yet 21:08:41 * nirik wonders if 740280 should be a beta blocker... it's on final now 21:08:44 only 738964 is proposed, and i believe we actually voted to accept it, just didn't update it... 21:08:54 did I miss that one? 21:09:00 * tflink checks logs 21:09:08 nirik: by the comment, no. 21:09:39 (if we pull the dracut update, no?) 21:09:55 #info we have fixes for 738803, 738964, but landed recently and we dont' have a compose with them yet. 21:10:03 no, we never had the version with no /dev/live in f16 beta tree, afaics. 21:10:03 adamw: the last meeting we left it as not enough info 21:10:17 tflink: oh, kay. well, i'm +1, based on our understanding of it now. 21:10:20 adamw: ok. 21:10:22 same here 21:11:35 tflink, adamw: is that 738964? (/me encourages everyone to use the power of their chair-age) 21:11:43 nirik: i just asked for info, but i'm pretty sure the dracut we have in the beta compose pile doesn't have the bug. 21:11:45 rbergeron: yes 21:11:52 #topic http://bugzilla.redhat.com/show_bug.cgi?id=738964 21:12:14 #info Unable to make system bootable due to bootloader choice 21:12:17 this is a nasty bug which took us quite a while to pin down: basically, the introduction of gpt disk labels in f16 causes some problems with the bootloader install logic 21:12:20 #link https://bugzilla.redhat.com/show_bug.cgi?id=738964 21:13:06 there is a non-well publicised fix in the form of an updates image 21:13:15 which we're currently testing 21:13:20 but I think that we're waiting for verification that liveinstall from usb still works 21:13:24 but, obviously, that's not gonna make release this week. 21:13:42 yeah, even if we did get a build today, I'd want to see more testing 21:13:51 the practical impacts of this depend on exactly what disks you have connected and what partitioning method you choose, but all of them kinda suck 21:14:24 not able to install the bootloader where you want, bootloader installed to a random usb stick you had plugged in, bootloader installed to the wrong disk overwriting the working one you had before, bootloader installed to the USB stick you're installing from... 21:14:26 it's just icky. 21:14:33 * nirik was again thinking we should have go/no-go on thursdays, but I suppose it's not possible to change that this cycle anyhow. ;( 21:14:47 * dgilmore needs /me needs to run 21:14:53 the fix, unfortunately, is quite heavy - anaconda will now stick a bios boot partition on any gpt-labelled disk it finds, as long as there's 1MB of space on it - so that's going to need some serious testing 21:15:03 nirik: but then would we just wind up saying, "we should do this friday" ? 21:15:39 :) yeah, it's a slippery slope... but I don't think as much time is needed for mirror syncing anymore... 21:15:45 nirik: honestly, i'd want to slip even if we had a day. we're really gonna need to be careful with the anaconda change. 21:15:58 +1 21:16:03 +1 21:16:04 yeah, understood... just saying. ;) 21:16:21 so, everyone's +1 blocker on this? 21:16:26 +1 21:16:31 yeah, +1 sadly 21:16:36 yes, sadface 21:16:53 I'd rather we slipped than took the risk of messing up people's data 21:17:02 (even if it's just the bootloader) 21:17:15 okay. So - is that the *only* thing seriously blocking us at this point? 21:17:19 (Other than, need to test, etc) 21:17:26 im +1 for blocker 21:17:28 proposed #agreed - 738964 - AcceptedBlocker - This can cause lots of problems with existing disks and installations. The fix needs quite a bit of testing by nature 21:17:30 * dgilmore really runs 21:17:37 The repoclosure problem is blocking us as well, right? 21:17:40 rbergeron: no 21:17:47 rbergeron: preupgrade is also an issue 21:18:05 jsmith: the repoclosure issue has a fix, though it's not obvious from the current blockers page 21:18:11 it just needs to pull in one specific update 21:18:11 * rbergeron is just eliciting as much info as possible at this point in as orderly a way as possible so everyone is on the same page as to level of breakage / priority. 21:18:18 that one i'm not worried about, we'd be on top of it for the next spin 21:18:33 tflink: ack 21:18:41 agree on this bug, then we'll discuss the others 21:19:07 * nirik is still sadly +1 21:19:08 ACK on tflink's proposal 21:19:12 #agreed - 738964 - AcceptedBlocker - This can cause lots of problems with existing disks and installations. The fix needs quite a bit of testing by nature 21:19:16 okay 21:19:27 #topic http://bugzilla.redhat.com/show_bug.cgi?id=738803 21:19:38 this is the one we've been stuck on most of the time - selinux denials booting the live image 21:19:52 we finally have a fix for it, but it only landed in working form this morning, again much too late to make the schedule 21:20:18 this one just turned out to be icky to identify and fix, it pinged back and forth between kernel and selinux, and there was another bug complicating matters (actually, two other bugs...) 21:20:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=738803 21:20:30 #info SELinux denial(s) prevent(s) gnome-shell from starting on F16 Beta RC1 21:21:23 mgrepl and dwalsh both gave it a good shot to fix it in time but in the end we couldn't manage it 21:22:04 so, hopefully we have fixes for both those soon and new rc later today/tomorrow? 21:22:13 pretty much, one more bug to flag up 21:22:25 #topic http://bugzilla.redhat.com/show_bug.cgi?id=737731 21:22:50 so this is similar to a bug that's fixed: it's to do with installing a new grub2 bootloader on upgrade 21:23:14 on an anaconda-based update, it pops up a dialog asking you what to do with the bootloader - we changed the default choice there to be more sensible, and kinda assumed preupgrade would use the new default 21:23:34 turns out it doesn't; preupgrade writes a bootloader line into the ks it feeds to anaconda, asking it to update the existing bootloader, which isn't possible for f16 21:23:40 so we need preupgrade to be changed 21:24:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=737731 21:24:21 so, i feel like that's a bit of a qa fail, but we had the other bugs anyway, so it wouldn't have made much of a difference. but we should've investigated more carefully. 21:24:26 #info Bootloader is left in F15 configuration when preupgrading to F16 21:24:57 (also, the fix will be in f15's preupgrade, so we have the 'slack' time to fix it, we don't need to fix it in time for f16 image compose 21:25:56 * nirik doesn't see any comments from maintainer there, hopefully it's on his radar. 21:26:18 nirik: i only just identified the issue there, so hughsie hasn't had much time. 21:26:22 i'm sure he'll get on it. 21:26:24 yeah. 21:26:41 #topic http://bugzilla.redhat.com/show_bug.cgi?id=735866 21:26:48 oh, we also have this one hanging around 21:26:51 the udevadm settle bug 21:26:54 LOL 21:26:56 "hanging around" 21:26:58 but i'm kinda souring on this one as a blocker 21:27:12 as it doesn't seem to happen to anyone *super* often, and no-one's come up with an explanation yet; it may be multiple bugs 21:27:22 we could probably just go with a commonbugs note for it 21:27:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=735866 21:27:34 #info boot hangs with udevadm settle - timeout of 120 seconds 21:27:34 rbergeron: just got no developer traction on it 21:27:41 i've pinged harald and kay a few times and got nothin' back 21:27:58 are they still travelling? /me wonders 21:28:20 no, back since two days ago i believe 21:28:56 i did get a passing mention from kay that udevadm settle hanging is 'usually' due to buggy kernel modules 21:29:14 so you're souring on it staying a blocker? 21:29:21 i am a bit, yeah. 21:29:21 or souring on it as in peeved that it's going nowhere 21:29:30 both? :) 21:29:30 * rbergeron looks for other opinions? 21:29:38 yeah, anyone else got a take on it? 21:29:42 going nowhere 120seconds at a time? ;) 21:29:44 heh 21:29:47 LOL 21:29:53 i don't think anyone's come out and said it happens to them EVERY boot yet 21:30:02 I'm pretty much of the same mind here - we haven't been seeing it all the time 21:30:03 and since the only 'blocker' impact is on the live installer, 'reboot a couple times' isn't a horrible workaround 21:30:06 nirik: going nowhere 120 seconds at a time to 10,000 leagues under the sea 21:30:06 and not much traction 21:30:07 I guess I'd be ok demoting it to a NTH... but continue to try and get somewhere with it. 21:30:33 in my mind the question is - would we hold release up until we had a fix for this? 21:30:49 Do we have an idea of what percentage of installs hit it? 21:30:50 if it was the only blocker left 21:31:03 * nirik re-skims the bug 21:31:03 jsmith: not really, we didn't get a lot of data 21:31:12 jsmith: i haven't seen other people reporting it on list or forums or other bugs either 21:31:18 * jsmith hit it 21:32:17 how related do we think it is to 734096? has fixing that changed anything? or unknown at this point 21:32:43 although harald said it's likely unrelated 21:33:09 i wouldn't guess super related... 21:33:14 oh, i see https://bugzilla.redhat.com/show_bug.cgi?id=670964 from f14, similar issue. 21:33:27 jsmith: how often do you hit it? 21:34:28 adamw: I hit it a few times in a row, but I don't remember what image I hit it with 21:34:52 can you boot the rc1 desktop live a few times and see if you hit it? 21:34:56 adamw: (I was also hitting selinux issues as well, so it was hard to tell which hangs were udev related and which were selinux) 21:35:01 adamw: Will do 21:35:07 with enforcing=0 to exclude selinux 21:36:07 * jsmith plays the "Gee, I wonder what data this USB key holds" game 21:36:10 okay, so in the meantime: do we want to NTH this one? or wait and see how testing goes for a day or two 21:36:34 * rbergeron prods us along 21:36:43 let's punt till friday 21:36:53 but i'm gonna be -1 blocker friday unless there's more data 21:37:01 okay. 21:37:13 same here, might as well wait for friday 21:37:27 #info will make final call on 735866 staying as blocker or not on friday 21:37:46 shall we go through the proposed list quickly? 21:37:49 most of them are -1s 21:37:50 yes please. 21:38:10 #topic https://bugzilla.redhat.com/show_bug.cgi?id=737774 21:38:37 adamw: that's already accepted 21:38:48 doesn't have a whiteboard 21:38:48 it blocks the repoclosure issue 21:39:14 * tflink didn't think that a blocker of a blocker needed accepted 21:39:16 my mistake 21:39:55 I'm +1 on this, it's a repoclosure issue 21:39:59 shall we accept it then? :) 21:40:02 well 21:40:03 +1 blocker, that is 21:40:09 if we leave it blocking f16beta, we should give it acceptedblocker 21:40:13 +1 blocker from me 21:40:14 or we can just stop it blocking f16beta in its own right 21:40:19 +1. 21:40:24 oh wait, it doesn't. sigh. 21:40:27 anyway. moving on 21:41:05 #agreed 737774 is a blocker 21:41:09 close enough! 21:41:13 #topic https://bugzilla.redhat.com/show_bug.cgi?id=739258 21:41:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=739258 21:41:38 #info Graphical firstboot runs, even if /etc/sysconfig/firstboot has RUN_FIRSTBOOT=NO 21:41:56 this is a jsmith special ;) 21:41:59 i couldn't reproduce this at all 21:42:04 Yeah... 21:42:07 LOL 21:42:09 could anyone else? 21:42:10 I can still hit it 21:42:11 * rbergeron snickers 21:42:36 jsmith: if you just run firstboot on a booted live image what happens? 21:42:37 Essentially, firstboot-graphical.service and firstboot-text.service were both enabled on the Live image 21:43:00 adamw: I'll double-check for you :-) 21:43:08 jsmith: they're known to be enabled 21:43:37 I don't think that I've seen firstboot on any livecd boot 21:43:40 but the RUN_FIRSTBOOT=NO should cause the firstboot process itself to just shut down right away 21:43:48 and apparently for everyone else it does ;) 21:44:03 i have a hard time seeing how it couldn't, as the check is in firstboot's code, i can't see how that file could exist and firstboot could still proceed 21:44:51 adamw: Booting that up now 21:45:32 oh wait, you have to run /etc/init.d/firstboot start , not just firstboot directly 21:45:56 adamw: OK, I'll do that -- just as soon as I get past the udevsettle delay :-/ 21:45:59 /etc/init.d/firstboot says: 21:46:03 FILENAME=/etc/sysconfig/firstboot 21:46:04 .. 21:46:11 if [ -f $FILENAME ] && [ ! -z "$(grep 'RUN_FIRSTBOOT=NO' $FILENAME)" ]; then 21:46:11 exit 0 21:46:11 fi 21:46:14 so...it's kinda...there. 21:46:44 Is there both a sysv-style initscript and systemd units? 21:46:55 the systemd unit calls /etc/init.d/firstboot start. 21:46:57 * jsmith speaks bad grammar 21:47:02 Ah... 21:47:24 maybe do the same on this - leave it until friday, demote to NTH if no more info? 21:47:27 yeah 21:47:35 * rbergeron nods 21:47:39 i think that crack-smoking reporter should put down the pipe and figure out what he's doing wrong 21:47:41 then we can downgrade it 21:47:42 ;) 21:47:42 LOL 21:47:45 +1 21:47:49 +1 21:48:05 +1... uh, I mean... no comment 21:48:07 (to tflink's proposal and the crack-smoking reporter comment, lol) 21:48:22 +1 to the leaving it til friday 21:48:34 propose #agreed 739258: jsmith is sure about this one but no-one else can reproduce, ask jsmith to look into it more closely and re-evaluate on friday 21:48:40 Just for that, I'll build a new USB key from scratch and try again. 21:48:46 ack 21:49:16 #agreed 739258: jsmith is sure about this one but no-one else can reproduce, ask jsmith to look into it more closely and re-evaluate on friday 21:49:36 739591 is closed already... 21:49:51 #topic https://bugzilla.redhat.com/show_bug.cgi?id=739345 21:50:08 seems straightforward if we need the new fedora-logos. 21:50:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=739345 21:50:19 #info pylorax throws an exception when used with fedora-logos-16.0.2 21:50:57 IIRC, we do if we want the dark grey splash for syslinux 21:51:23 if we use 16.0.1, the splashes will be black 21:51:30 but lorax won't crash 21:51:54 technically this is probably nth, as the artwork bug is nth 21:51:55 I'm +1 blocker on this 21:52:06 * jsmith leans towards blocker 21:52:08 but in practice it might be best to keep it blocker to make sure we don't screw up and pull the new logos but not the new pylorax 21:52:18 you need to get both 21:52:22 right 21:52:22 Right... 21:52:28 if you pull in the new lorax and the old logos, it'll still crash 21:52:33 ah 21:52:46 the problem is in hard-coded paths in lorax 21:52:57 yeah, i see 21:52:58 if it doesn't find the right files, it throws an exception 21:53:05 so of course you should've fixed them not to be hardcoded ;) 21:53:16 let's keep it blocker, it makes things safer 21:53:47 it's not like we'll get very far without getting this right :-D 21:53:51 true 21:54:13 propose #agreed 739345 is a blocker as it can make it impossible to generate DVDs 21:54:19 s/DVDs/images 21:54:20 ack 21:55:31 ack 21:55:39 ack 21:55:48 #agreed 739345 is a blocker as it can make it impossible to generate images 21:56:14 #topic https://bugzilla.redhat.com/show_bug.cgi?id=739910 21:56:26 this one seems clearly -1 as the affected gnome-packagekit isn't actually in beta 21:56:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=739910 21:56:46 #info gnome-packagekit fails when trying to update - The package id's '' are not valid 21:57:00 as in the comments, I'm also -1 blocker, -1 NTH on this 21:57:18 * tflink needs to leave 21:57:48 * nirik is -1 21:57:59 tflink: fly, my pretty 21:58:05 anything you wanted to flag up for us? 21:58:28 I don't think so, we've hit the big ones 21:58:34 k 21:58:43 Okay. Can we call this a no-go now? 21:58:49 it clearly is 21:58:59 but we do that at the end, right? 21:58:59 * tflink is still confused on 739253 since he can't see power options from gdm greeter but that isn't a blocker/noblocker issue 21:59:08 tflink: yeah, i'll note that detail 21:59:10 no-go 21:59:50 so, we're -1 on 739910? berge? 22:00:11 -1 from me 22:00:14 that's 3! 22:00:22 oh, i thought you said "we hit the big ones" 22:00:24 -1 22:00:35 sorry, i missed the link 22:00:35 propose #agreed 739910 is not a blocker or nth as the affected gnome-packagekit is not in the beta frozen package set 22:01:22 ACK 22:01:47 ack. 22:01:53 #agreed 739910 is not a blocker or nth as the affected gnome-packagekit is not in the beta frozen package set 22:01:55 aCk 22:02:19 #topic https://bugzilla.redhat.com/show_bug.cgi?id=739253 22:03:11 so the criteria require power management options presented by the desktop to work: "All release-blocking desktops' offered mechanisms (if any) for shutting down, 22:03:11 logging out and rebooting must work" 22:03:53 there's a couple of twists to this one: you could argue that doesn't cover the login manager (though really, we've always considered that it does), and some people are seeing gdm *not present* any pm options - which is not actually a blocker case... 22:03:54 does that imply in the desktop? 22:03:55 * jsmith leans toward blocker on this one, but is worried about the lack of consistency in the feedback 22:04:10 i think the good news is no-one's said that with 3.1.92 they got broken PM options 22:04:20 they either get working ones or none - both of which are not blocker scenarios, heeh 22:04:59 you would think it would offer poweroff all the time tho, no? 22:05:00 but anyway - the original bug does look blockerish. 22:05:13 nirik: you'd think, yeah. but if it doesn't...per the current criteria, we don't care. 22:05:22 (though maybe we should.) 22:05:23 yeah. 22:05:42 i'm probably +1 blocker here, and try and plumb out what's going on with some people seeing options and others not 22:06:05 * nirik is +1 blocker, but would like to see if we can be more consistent in the solution... 22:06:54 yeah, it worries me that everyone is having a variety of experiences 22:07:00 +1 22:07:18 how about +1 blocker to fix the real issue, and another bug to make it consistent for final? 22:07:37 #agreed 739253 is a blocker per criterion "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work" 22:07:45 Awesome :-) 22:07:48 #topic https://bugzilla.redhat.com/show_bug.cgi?id=672023 22:07:58 #action adamw to follow up on 739253 with halfline 22:08:18 this feels more nth than blocker to me\ 22:08:31 15? 22:08:35 it's not like it means abrt doesn't submit the backtrace, just that it'll allow you to continue without one 22:08:41 nirik: seems like this is an old bug that came back 22:08:44 see the last couple of comments 22:08:53 Are there any criteria that this hits? 22:09:24 not really 22:09:38 The comment says " proposing as a beta blocker since this can create a lot of noise in bz" 22:09:51 I'm not sure that's a current criterion 22:09:55 * nirik is ok with NTH, -1 blocker 22:10:00 So I'd personally say NTH, -1 blocker 22:10:36 actually..do we really want to give it even nth? 22:10:48 Yeah, I think we do 22:10:59 well, it'd only affect the live image really 22:11:19 although actually, that's an important scenario i guess, because it's hard to get a full trace on the live...and we really don't want a ton of live reports with no trace 22:11:23 so yeah...nth is good. 22:12:22 propose #agreed 672023 does not hit any criteria, but it would be good to avoid getting crash reports from the live image with no trace: rejectedblocker, acceptednth 22:12:43 ack 22:12:50 ACK 22:12:50 ack 22:12:56 #agreed 672023 does not hit any criteria, but it would be good to avoid getting crash reports from the live image with no trace: rejectedblocker, acceptednth 22:13:15 okay, that's proposed blockers...there's one more bug dlehman had a question about 22:13:24 adamw: Let's discuss it! 22:13:34 #topic https://bugzilla.redhat.com/show_bug.cgi?id=731549 22:13:58 so this is about the message anaconda pops up when you need a BIOS boot partition but you haven't created one 22:14:05 the original message was pretty hard to understand 22:14:09 mo and i came up with a better one 22:14:31 but we're past string freeze, and neither me, mo or dlehman really understands the implications of that - do we need to get an exception to change a message like this now? 22:15:14 No, but a heads up to the translation team would be nice 22:15:28 okay 22:15:33 Just let them know that there will be a few strings that need to be updated in anaconda, and I think we'll be OK 22:15:41 * nirik nods. 22:15:41 would it break anything for dlehman to just change the string and roll a new anaconda build? 22:15:44 I think thats fine. 22:15:55 adamw: Just make sure he pushes the strings to tx.net after doing so 22:16:00 okay 22:16:11 we'll try and sort that out 22:16:22 does he need to wait for translations before building the new anaconda package? 22:16:32 Might not hurt to ask on the translation list, just to make sure 22:16:44 If he doesn't wait for translations, they'll see that message in English 22:16:54 okay 22:16:57 https://admin.fedoraproject.org/mailman/listinfo/i18n 22:17:11 thanks for the info 22:17:52 trans@lists.fedoraproject.org 22:18:16 ah yeah, possibly better 22:18:22 #action adamw and dlehman to co-ordinate fix for 731549 with i18n team 22:19:40 i think that's all the bugs we need to discuss... 22:19:43 anything i missed? 22:19:56 * rbergeron prays 22:20:21 * nirik has nothing more... is there a final 'no-go' vote? ;) 22:20:31 That's next, if we are not missing bugs. :) 22:20:38 let's move on quick! 22:21:30 #topic Go/No Go 22:21:41 So I think we're pretty much at a no-go. 22:21:47 Agreed? 22:22:02 qa votes no: there are outstanding unresolved blockers in the current candidate build 22:22:36 * jsmith votes "No Go" 22:22:45 #info qa votes no, outstanding unresolved blockers in the current candidate build. 22:22:51 #info jsmith, rbergeron also vote no-go. 22:23:08 yeah, no-go. ;( 22:23:15 Okay. 22:23:20 Rel-eng had to go, but on behalf of Dennis, I'll say no-go for him :-) 22:23:27 #agreed We are a no-go for Beta. 22:23:33 well, foo. 22:23:47 #info We will regroup next Wednesday, same time, for another go/no-go, as well as having another blocker meeting Friday. 22:24:16 #info Release readiness meeting will happen tomorrow as planned. 22:24:24 Anything else? 22:24:32 #action rbergeron to send out mail, notify, update the schedule. 22:24:49 sorry about this one folks :( we took an extra week testing time but still didn't make it, sigh 22:25:25 adamw: yeah, do we think that made a difference? 22:25:31 Would we be slipping 2 weeks? :) 22:25:37 it's certainly possible 22:25:38 rbergeron: I honestly think so 22:25:44 i don't feel like we sat on our hands that extra week 22:25:45 Okay. Just curious 22:25:47 * rbergeron nods 22:26:04 okay. Well folks: Thanks for coming. 22:26:09 See y'all next week. 22:26:16 22:26:28 thanks everyone. Sorry it couldn't be better news. ;( 22:26:35 #endmeeting