17:00:07 <jreznik> #startmeeting F19 Alpha Go/No-Go meeting
17:00:07 <zodbot> Meeting started Thu Apr 18 17:00:07 2013 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:22 <jreznik> #meetingname F19 Alpha Go/No-Go meeting
17:00:22 <zodbot> The meeting name has been set to 'f19_alpha_go/no-go_meeting'
17:00:34 <jreznik> #topic Roll Call
17:00:43 * satellit listening
17:00:56 <jreznik> hey! who's around?
17:02:39 * nirik is here.
17:02:49 <nirik> may need to do a quick reboot here in a sec tho.
17:03:13 <jreznik> let's wait a moment for more people to come, I moved the meeting to -2 channel, not to overflow into board meeting in case we would need it
17:03:46 * nirik will be back in a min
17:03:49 <jreznik> #chair nirik tflink adamw rbergeron
17:03:49 <zodbot> Current chairs: adamw jreznik nirik rbergeron tflink
17:03:53 * tflink is here
17:05:47 <jreznik> ok, let's start - and let's hope nirik make it before we start real "work" here
17:05:59 <jreznik> #topic Purpose of this meeting
17:06:08 <jreznik> #info Purpose of this meeting is to see whether or not F19 Alpha is ready for shipment, according to the release criteria.
17:06:12 <jreznik> #info This is determined in a few ways:
17:06:17 <jreznik> #info No remaining blocker bugs
17:06:23 <jreznik> #info Test matrices for Alpha are fully completed
17:06:29 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/19/alpha/buglist
17:06:35 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC4_Install
17:06:42 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC4_Base
17:06:49 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_RC4_Desktop
17:06:54 <jreznik> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
17:07:33 <adamw> did you ping dgilmore?
17:08:51 <jreznik> thanks for ping, and I hope rbergeron will show up too (chair should did it)
17:09:31 * rbergeron is here, albeit via phone irc, as the internets apparently aren't available at cloud conferences, or at marriotts in rooms where i sleep.
17:09:56 <jreznik> rbergeron: cloud does not need internet!
17:10:56 * satellit afk
17:11:02 <jreznik> for accepted blocker bugs - there's no unresolved bug
17:11:28 <jreznik> we have one proposed bug - so let's start with mini blocker review as alway, tflink, may I ask you?
17:11:38 <tflink> sure
17:12:03 <tflink> do we want to go through the accepted blockers as well?
17:12:17 <adamw> "for accepted blocker bugs - there's no unresolved bug"
17:12:33 <jreznik> and I think we covered it pretty well yesterday
17:12:38 <tflink> just making sure
17:12:54 <tflink> #info right now, we have 1 proposed blocker for F19 alpha
17:13:03 <tflink> #topic (953447) EFI boot on Mac halts after GRUB
17:13:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=953447
17:13:03 <tflink> #info Proposed Blocker, lorax, NEW
17:14:42 <adamw> so, two macs are busted
17:14:50 * adamw attempts to engage his caring circuits
17:14:51 <tflink> it sounds like this is a variant of the failing-to-boot-post-install bug
17:15:00 <adamw> i don't think so, i think satellit is muddying the waters
17:15:19 <adamw> all we know is that USB EFI boot of an F19 RC4 image failed on two macs.
17:15:30 * nirik is back
17:15:56 <adamw> i'd like to get data from a few more macs really, but we don't really have time. mjg59 is on the other side of the country from his, and I haven't seen cmurf this cycle.
17:16:01 <adamw> anyone here have a mac?
17:16:26 * tflink has an older one
17:16:39 <tflink> I think it's new enough to work, though
17:16:40 <nirik> were we still excluding macs due to their 'interesting' efi?
17:16:43 <nirik> (as a blocker)
17:16:43 <spot> I can test on the current uefi macs
17:16:46 * spot has them
17:16:50 <adamw> spot: ooh, can you? thanks
17:16:55 <adamw> shouldn't take long
17:17:03 <adamw> shall we wait for tflink and spot to test?
17:17:23 <jreznik> nirik: that's a good question, seems like other uefi systems are not affected by this one
17:17:25 <adamw> i think all that's needed is to write dvd or netinst to a usb stick and try to do an EFI boot from it.
17:18:01 <adamw> we took the 'mac exception' out of the criteria kinda on purpose, but we have some wiggle room in how they're currently written: this just comes down to the old 'how widespread is the bug' judgement call
17:18:12 <adamw> we can spin it 'ahh! all macs are broken!' or we can spin it 'eh, there aren't that many macs'.
17:19:23 * nirik nods. ok
17:19:40 * jreznik is ok with waiting for guys to retest and also with what we already did on efi side - few more macs are probably not a big issue at this time, just my thinking
17:20:45 <tflink> something odd is going on, trying again with more debug
17:21:18 * rbergeron suspects we have far lower usage as a total coming from macs during alpha/beta vs. final
17:22:55 <jreznik> spot: are you trying it too?
17:23:45 <spot> jreznik: yes
17:23:53 <spot> making the usb key off the netinst iso of tc6 now
17:24:15 <jreznik> we need rc3 at least
17:24:30 <spot> whoops. :/
17:24:48 <jreznik> looking on https://bugzilla.redhat.com/show_bug.cgi?id=949761#c29
17:25:04 <adamw> spot: rc4 netinst should be fine
17:25:07 <spot> my fault, I parsed right to the end of the file list
17:25:29 <spot> just a few more minutes.
17:25:35 <tflink> it seems to be something really early in the boot process - removing quiet and adding rd.debug does nothing
17:26:53 <tflink> is there anything I can add to the cmdline to get more debug output?
17:27:09 <adamw> tflink: is yours failing at the same place as the reporters?
17:27:13 <adamw> right after grub?
17:27:14 <tflink> yeah
17:27:30 <spot> okay, writing out to usb now
17:27:33 <adamw> so, that's another confirm
17:27:34 <tflink> it seems to load the initrd and just stop in its tracks
17:27:47 <adamw> i guess pjones/mjg59 would be the ones who could possibly debug it
17:27:55 <adamw> speaking of...
17:27:58 <jreznik> adamw: I just pinged him
17:28:29 <jreznik> pjones: [19:25] <tflink> it seems to be something really early in the boot process - removing quiet and adding rd.debug does nothing
17:28:32 <adamw> pjones: so now we have three confirmations that Macs just apparently die right after grub when booting USB-written RC3/RC4 images.
17:28:34 <jreznik> [19:26] <tflink> is there anything I can add to the cmdline to get more debug output?
17:28:38 <pjones> cool.
17:29:02 <nirik> tflink: perhaps add initcall_debug ?
17:29:14 <tflink> I just did another uefi install with the same usb drive, so I'm reasonably sure that the media is OK
17:30:03 <spot> the macbook pro stops after "Secure boot not enabled"
17:30:30 <jreznik> so confirmed too
17:30:49 <pjones> spot: so you've actually got one in front of you?
17:30:58 <spot> pjones: yes
17:31:00 <tflink> pjones: I do as well
17:31:06 <pjones> tflink: spot: the original reporter isn't very clear - do you actually see grub at all?
17:31:13 <spot> yes
17:31:15 <tflink> nirik: no dice, that didn't give me more output
17:31:23 <spot> grub loads fine, kernel starts to boot
17:31:32 <pjones> alright, kernel issue.
17:31:37 <pjones> you need jwb, not me ;)
17:32:00 <tflink> something starts to boot, it pulls stuff from the disk and then just stops
17:32:01 <adamw> still, i'm not sure we really need to live debug in the meeting
17:32:10 <tflink> true
17:32:12 <adamw> we're not gonna be able to fix it, respin and re-test in the next six hours
17:32:15 <adamw> so we either ship it or we don't
17:32:26 <pjones> mac has always been a sort of "best effort" thing in the past.
17:32:28 <spot> i dont think macs are an alpha blocker. beta, sure.
17:32:33 <pjones> I really don't think it should be an alpha blocker.
17:32:40 <pjones> beta would be... awfully nice of us.
17:32:48 <jreznik> jwb: hi
17:32:50 <jwb> hello
17:32:53 <adamw> yo
17:32:56 <adamw> join the Mac party
17:33:04 <jwb> also, you should probably drag jforbes in here.  he's on f19 duty
17:33:52 <tflink> eh, I think there's no realistic way we could fix this, respin and retest in 6 hours (like adamw said before)
17:34:09 <adamw> right, we can just do the debugging in #fedora-kernel or whatever
17:34:12 <jwb> just so you're aware, i ahve no idea what you're talking about
17:34:16 <adamw> sorry
17:34:31 <adamw> the bug in #topic - looks like EFI boot on all Macs is busted in RC3/RC4
17:34:36 <tflink> the question becomes whether we're OK with releasing alpha without mac support
17:34:38 <jreznik> jwb: see topics, seems it passes grub and then...
17:34:51 <adamw> has anyone tried with an actual silver disc yet, btw?
17:34:52 <tflink> I thought that dd prepared media was supposed to still work
17:35:04 * tflink has not
17:35:11 <adamw> oh, did you all use litd?
17:35:23 <adamw> we should check dd, litd, actual disc, to see exactly what the status is
17:35:31 <adamw> by 'we', of course, i mean 'you'
17:35:37 <rbergeron> that's "the royal we"
17:35:53 <jreznik> adamw: from the bug: 1. Create USB stick with RC3/4 using either litd or dd
17:35:58 <jwb> mac images have some kind of weird, perverted el torito thing done to them in order to boot, don't they?
17:36:01 <adamw> ah, so satellit tried both
17:36:10 * rbergeron isn't sure how many macs even have drives for that these days?
17:36:11 <adamw> jwb: i think that's for *BIOS* boot on macs
17:36:25 <tflink> it's still oversized :-/ won't fit on a DVD
17:36:47 <pjones> jwb: they do, but the bootloader is working, so we're seeing the file system fine
17:37:12 <pjones> I doubt if it's a disk formatting issue
17:37:35 <spot> it's getting far enough to print "Secure boot not enabled"
17:37:50 <jreznik> btw. there are not many changes between tc6 and rc3 accepted (and even new lorax wasn't used for rc3)
17:37:53 <jwb> spot, the kernel doesn't print that
17:38:04 <spot> jwb: the shim does, right?
17:38:12 <jwb> spot, yes, which runs before grub
17:38:18 <pjones> jwb: spot and tflink say that after they select a boot option it loads from the disk for a while and then stops - my assumption would be that it's simply faulting before fbcon comes up
17:38:23 <jwb> uefi->shim->grub->kernel
17:38:42 <spot> that is the only thing printed on the fb.
17:38:47 <jwb> the bug says "mac mini"
17:38:51 <jwb> is that the 32-bit mac mini?
17:38:55 <jwb> because just no
17:39:02 * spot can reproduce it on the current macbook pro
17:39:13 <jwb> ok
17:39:32 <spot> if i change the grub config options and F10 boot it, it prints "Booting a command list"
17:39:47 <spot> but aside from the shim print, thats it
17:40:27 <pjones> right, that's being printed when grub calls shim's verify routine to verify the kernel is signed properly
17:40:33 <spot> adamw: i can burn netinst to cd, one sec
17:40:33 <jwb> someone said adding GRUB_TERMINAL_OUTPUT=console makes it boot?
17:40:39 <pjones> which means we know a) we're able to read the kernel, and b) it works
17:40:43 <adamw> jwb: ignore that, it's satellit muddying the waters
17:40:54 <pjones> jwb: I... kind of suspect that he's simply commented on the wrong damned bug
17:41:14 <adamw> pjones: no, but he wrote a very confusing comment. the real takeaway from that is that it worked with TC6 but it doesn't with RC3/RC4
17:41:19 <adamw> (which seems odd in itself, but hey)
17:41:27 <adamw> if spot/tflink want to double check that at some point it'd be helpful i guess
17:41:35 <jwb> so essentially what we're left at is that grub loads the kernel, and then that's it
17:41:40 <jwb> does it load the initramfs?
17:42:13 <pjones> so what somebody needs to do is to get F18 on one of the machines and try updating each of grub-efi and kernel individually and together on the installed machine.
17:43:19 <pjones> If one of them fails, we have a culprit.  If they work fine together, then it really is the media, but since shim is validating kernel correctly, I doubt that.
17:43:25 <adamw> so the most likely candidate that changed between TC6 and RC3 - assuming that satellit is correct that TC6 worked - is kernel
17:43:26 <mjg59> Take an F19 live USB image. Mount the HFS+ filesystem on it. Copy over grub.efi from F18.
17:43:26 <jreznik> spot: could you retry it with that tc6? so it will have use too...
17:43:28 <jwb> on my one UEFI machine, which is not a Mac, grub will print out 'Loading initial ramdisk...' before the kernel is started
17:43:49 <pjones> jwb: whether or not you see that depends on particulars of the uefi implementation, sadly.
17:43:56 <adamw> TC6 had kernel-3.9.0-0.rc6.git2.1.fc19 , RC3/RC4 have kernel-3.9.0-0.rc6.git2.3.fc19
17:43:59 <jwb> pjones, ah.  i see.  unfortunate
17:44:14 <tflink> jwb: not sure, it loads something from the usb disk but I'm not sure what
17:44:33 <adamw> the only other things that changed were lorax (which could _feasibly_ have something to do with it, but it seems unlikely), anaconda, python-blivet and gnome-session
17:44:40 <pjones> anyway, somebody with a box needs to do what either I or mjg59 has said.
17:44:44 <adamw> ok
17:44:46 <pjones> and then we'll know which thing is busted.
17:44:50 <jwb> or both
17:44:58 <pjones> sure.
17:44:58 <jreznik> adamw: well, according to the comment, new lorax wasn't used for rc3
17:45:01 <adamw> oh right
17:45:12 <adamw> so again, assuming TC6 vs. RC3 is correct, the only plausible suspect is the kernel
17:45:32 <jwb> i do not have a mac, and i don't think anyone else on the kernel team does.  if we did, we would have been testing this for a while now given how troublesome they are
17:45:32 <tflink> jwb: the bug was reported on a newer mac mini - 64bit afaik
17:45:41 <jreznik> so pls guys, try tc6
17:45:55 <mjg59> Ok
17:45:58 <mjg59> So that thing that I said to try?
17:45:59 <mjg59> Try it.
17:46:08 <mjg59> Because that actually provides useful information
17:46:08 <adamw> tflink: you heard the man
17:46:25 <tflink> did I miss something?
17:46:27 * tflink looks
17:47:30 <adamw> i think they're talking about:
17:47:31 <adamw> <pjones> so what somebody needs to do is to get F18 on one of the machines and try updating each of grub-efi and kernel individually and together on the installed machine.
17:47:34 <adamw> <pjones> If one of them fails, we have a culprit.  If they work fine together, then it really is the media, but since shim is validating kernel correctly, I doubt that.
17:47:37 <adamw> <mjg59> Take an F19 live USB image. Mount the HFS+ filesystem on it. Copy over grub.efi from F18.
17:47:48 <adamw> i'm not sure if there was a *second* step to mjg59's idea :)
17:48:00 <tflink> yeah, seeing that now
17:48:12 <pjones> Well, his version is half of my version.
17:48:22 <pjones> I assume if grub works he'll tell you to copy a kernel in.
17:48:24 <tflink> odd, the shiny disk shows up with 3 bootloaders titled 'windows', and 2x 'EFI boot'
17:48:36 * tflink is starting to modify the live image
17:48:41 <adamw> yeah, cmurf and satellit have mentioned that before. there's some reason for it. i don't recall what.
17:48:48 <rbergeron> murphy
17:48:56 <mjg59> If one of them doesn't say "Fedora" then something's broken
17:49:22 <adamw> so, let's give this the old college try once more:
17:49:30 <adamw> can we do the debugging in #fedora-kernel and do the blocker discussion here?
17:49:51 <adamw> i mean, it seems pretty clear now that this affects all (or at least a lot of) macs, but doesn't affect anything else.
17:50:09 <jreznik> it is
17:50:38 <tflink> yeah, sounds like a plan
17:50:39 <jreznik> and it's probably too late to do anything with it now
17:51:04 <tflink> so it sounds like we're mostly -1 on this
17:51:12 <adamw> oh, well there's T.C. Hollingsworth's bug that sounds kinda similar - https://bugzilla.redhat.com/show_bug.cgi?id=951761 - but I don't think it's the same.
17:51:13 <tflink> if not unanimously?
17:51:25 <adamw> the dev take seems to be generally -1
17:51:31 <adamw> i wouldn't really fight a -1
17:51:51 <adamw> though it might be nice if we could ninja out an image that works for mac folks a week later or something.
17:52:00 <jreznik> and looking on what we already did with uefi, I'm -1 too
17:52:17 <pjones> yes, we're unanimously against mac blockers.
17:52:20 <pjones> (dev, that is)
17:52:21 <jreznik> adamw: or beta TCs will follow soon
17:52:45 <adamw> rbergeron: are you with jreznik?
17:52:47 <rbergeron> adamw: i think that seems reasonable
17:52:56 <rbergeron> adamw: physically?
17:52:57 <tflink> proposed #agreed 953447 - RejectedBlocker - While this does seem to affect all apple hardware, that isn't enough to block F19 alpha over. Thus, this is rejected as a blocker for F19 alpha.
17:52:59 <adamw> okay, so dev and management are -1 and qa is pretty meh. sounds like -1 to me
17:53:01 <rbergeron> or in spirit/mind
17:53:08 <adamw> rbergeron: like, spiritually, maaaan
17:53:10 <rbergeron> opinion :) yes.
17:53:22 <adamw> ack
17:53:32 <tflink> ack/nak/patch?
17:53:34 <jreznik> tflink: maybe patch it with adamw's idea to spin mac version later?
17:53:41 <adamw> eh, let's keep that unofficial./
17:53:48 <rbergeron> if we had more folks reporting; i honestly don't know that we have a ton of mac usage until post-release. clearly not here for rc's though. (sadly)
17:53:48 <jreznik> ok
17:53:50 <tflink> yeah, agreed
17:53:57 <rbergeron> ack, and agree iwth adam re: unofficial hope
17:54:16 <jreznik> ack, not promising something we don't know we can fulfil
17:54:16 <adamw> rbergeron: satellit and cmurf are two people who reliably test on macs. satellit's reports can be frustrating to interpret, though.
17:54:25 <jwb> if you suspect this is kernel, then you guys should really CC the kernel team because this is the first i've heard of this bug
17:54:30 <jwb> for future reference
17:54:30 <jreznik> adamw: or jskladan
17:54:39 <adamw> jwb: the reporter guessed at lorax, but it sounds more kernel-y, so i'll re-assign
17:54:44 <tflink> jwb: it was filed less than 24 hours ago
17:54:56 <dgilmore> adamw: i can test on a mac
17:55:16 <jreznik> do we have enough acks now?
17:56:12 <tflink> ah, missed one
17:56:20 <tflink> #agreed 953447 - RejectedBlocker - While this does seem to affect all apple hardware, that isn't enough to block F19 alpha over. Thus, this is rejected as a blocker for F19 alpha.
17:56:23 <rbergeron> adamw: yeah, just saying the overall % of folks i think are affected is low. worst case: we bring irritated people out of the woodworks with the alpha and have a slightly better guestimation :)
17:56:31 <tflink> that would be all of the proposed blockers
17:56:45 <tflink> unless there's been one proposed since we started the meeting
17:57:07 <jreznik> don't see any, at least picked up by the app
17:57:39 <adamw> i have one
17:57:44 <adamw> not officially proposed, but one to bring up
17:57:56 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=953329
17:58:07 <adamw> i hit that a couple of times last night trying to install to very blank disks
17:58:29 <adamw> i kinda owe bcl some data and a clear reproducer, but wanted to bring it up just in case it makes anyone poop bricks
17:58:41 <adamw> the good-ish news is that both times I hit it, rebooting and trying again worked, so there's an 'obvious' workaround
17:59:00 <jreznik> commonbugs?
17:59:05 <tflink> yeah
17:59:43 <dgilmore> adamw: document but if it works second time its a reasanoblish workaround for alpha
18:01:11 <adamw> has anyone else tried an install to a very 'blank' disk, just out of interest?
18:01:38 <adamw> one time I hit it on a disk I had wiped all partitions from and created a new disk label using 'fdisk', the other time was a disk that had been part of a RAID array that I destroyed
18:01:46 <jreznik> aren't virt installs usually blank disks?
18:03:09 <adamw> jreznik: it kinda depends on your testing method. not for me - I just re-use a couple of VMs over and over.
18:03:16 <tflink> I did a new virt install yesterday with RC3, it went fine
18:03:37 <tflink> just-created lv as a backing store
18:03:37 <adamw> good news.
18:04:35 <jreznik> adamw: do you want this one to go formally though the review or just mark it as commonbugs? as it seems tflink did blank install
18:04:35 <adamw> sounds like no-one's too worried about this one. or we just all want to release the alpha and go drink. :)
18:04:41 <adamw> commonbugs is fine
18:04:42 <adamw> already marked
18:04:51 <jreznik> ok
18:05:08 <jreznik> so anything else for mini blocker review?
18:05:28 <tflink> nothing I'm aware of
18:06:20 <jreznik> #info after mini blocker review, there are no accepted & unresolved blocker bugs
18:06:55 <jreznik> #topic Test matrices coverage
18:07:12 <jreznik> (see links above)
18:08:10 <adamw> looks fine
18:08:22 <adamw> KDE tests are from RC3, but that shouldn't be a problem, no KDE-related changes in RC4.
18:08:33 <adamw> install and base are covered afaics. except the perennial SCSI.
18:09:09 * nirik poked at the Xfce spin the other day FWIW, and it seemed to work fine for me.
18:09:37 <dgilmore> LXDE is known broken right adamw ?
18:10:02 <adamw> yeah
18:10:08 <jreznik> anyone to do a really quick - does kde boots test? my virt-manager is broken for some reason, asked kde guys to take a look but... I expect everything is ok as the changes between rc3/rc4 were low
18:10:22 <adamw> sure, i can do that.
18:12:10 <adamw> KDE live x64 boots fine, starting an install.
18:12:30 <jreznik> ok, thanks
18:13:05 <adamw> install's running fine. looks a-ok.
18:13:36 <jreznik> well, I think we can move on
18:14:22 <jreznik> #info test matrices coverage looks good
18:15:04 <jreznik> #info KDE tests are copied from RC3, with quick RC4 test up to installation, no KDE-related changes in RC4
18:15:25 <jreznik> #info install and base are covered except the perennial SCSI
18:15:38 <jreznik> #topic Go/No-Go decision
18:16:13 <jreznik> we are here for Alpha! the Go/No-Go decision
18:16:26 <dgilmore> releng is +1 to go
18:16:31 <jreznik> adamw: may I ask you for QA?
18:16:45 <jreznik> #info releng is +1 go
18:16:53 <jreznik> rbergeron: you as FPL?
18:17:36 * nirik is +1 for go.
18:17:57 <jreznik> #info fedora program manager is +1 to go
18:18:25 <rbergeron> yes, go, based on things as i see the scrollback of slightly
18:18:26 <rbergeron> :)
18:18:27 <rbergeron> +1
18:18:32 * jsmith is +1 for go as a nobody/ex-FPL, for what little it's worth
18:18:52 <adamw> QA is go per our requirements
18:19:36 <adamw> "QA approves the release if all validation tests appropriate to the release phase (Alpha, Beta or Final) have been performed and there are no accepted blocker bugs that are unaddressed in the candidate compose."
18:19:39 <jreznik> #info FPL is +1 to go (and ex-FPL too)
18:20:05 <jreznik> #info QA is +1 go per requirements
18:20:25 <jreznik> #info QA approves the release if all validation tests appropriate to the release phase (Alpha, Beta or Final) have been performed and there are no accepted blocker bugs that are unaddressed in the candidate compose.
18:20:44 <jreznik> ok, I think we are all set
18:21:25 <jreznik> proposed #agreed Fedora 19 Alpha is +1 to go by QA, FPL, releng, FPGM and developers
18:22:18 <jreznik> any acks/nacks/patch
18:22:37 <tflink> ack
18:23:32 <adamw> ack
18:23:39 <adamw> tflink: your 'proposed #agreed' meme is spreading :)
18:23:45 <nirik> ack
18:23:56 <dgilmore> ack
18:23:57 <jreznik> adamw: another qa patent?
18:24:11 <jreznik> #agreed Fedora 19 Alpha is +1 to go by QA, FPL, releng, FPGM and developers
18:24:12 <adamw> yes. you owe us ONE MEEEEEELLION DOLLARS
18:24:26 <tflink> assuming it works better than the non-deterministic fuse :)
18:24:27 <dgilmore> adamw: ill buy you a beer
18:25:11 <jreznik> ok guys, thank you for coming, thanks for a great job on alpha!
18:25:29 <tflink> whee!
18:25:53 <jreznik> without  that uefi mess, we would even beat ourselves and release on time :)
18:25:56 <adamw> yay. let's drink
18:26:03 <adamw> proposed #agreed UEFI stinks
18:26:11 <tflink> ack
18:26:12 <jreznik> ack
18:26:24 <adamw> i imagine there isn't an 'ack' big enough for mjg59
18:26:45 <jreznik> #info jreznik to announce result of Go/No-Go meeting
18:27:28 <jreznik> otherwise I think infra is ready to mirror bits, websites guys would need checksums for final isos
18:27:54 <jreznik> adamw: I expect you will try to put commonbugs page together, right?
18:29:44 <jreznik> nirik: ^^^ (one line off)
18:29:47 <adamw> sure
18:30:05 <nirik> yep. should be all set.
18:30:11 <jreznik> thanks
18:30:32 <jreznik> anything else to bring up? /me hopes not and setting the fuse (deterministic one)
18:30:53 <jreznik> 3...
18:33:13 <jreznik> 2...
18:33:13 * adamw taps on fuse
18:33:32 <jreznik> 1...
18:33:41 <jreznik> and adamw taps fuse
18:33:44 <jreznik> thanks again!
18:33:48 <jreznik> #endmeeting