17:04:44 <jreznik> #startmeeting F22 Beta Go/No-Go meeting - 2
17:04:44 <zodbot> Meeting started Thu Apr 16 17:04:44 2015 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:04:46 <jreznik> #meetingname F22 Beta Go/No-Go meeting - 2
17:04:46 <zodbot> The meeting name has been set to 'f22_beta_go/no-go_meeting_-_2'
17:05:22 <jreznik> sorry for messing up meeting room reservation... :)
17:05:35 <jreznik> #topic Roll Call
17:06:03 <jreznik> so, who is here for go/no-go fun today?
17:06:30 <sgallagh> .hello sgallagh
17:06:32 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:06:38 * satellit listening
17:06:50 * kalev_ lurks.
17:06:51 * kparal is here
17:07:09 <gary_buhrmaster> gary_buhrmaster lurks
17:07:15 * striker watching
17:07:43 <jreznik> #chair sgallagh adamw kparal nirik
17:07:43 <zodbot> Current chairs: adamw jreznik kparal nirik sgallagh
17:07:51 <nirik> morning
17:07:57 * oddshocks here
17:08:01 <oddshocks> .hello oddshocks
17:08:07 <zodbot> oddshocks: oddshocks 'David Gay' <dgay@redhat.com>
17:08:16 <jreznik> #topic Purpose of this meeting
17:08:17 <jreznik> #info Purpose of this meeting is to see whether or not F22 Beta is ready for shipment, according to the release criteria.
17:08:18 <adamw> .hello adamwill
17:08:19 <zodbot> adamw: adamwill 'Adam Williamson' <adamw+fedora@happyassassin.net>
17:08:19 <jreznik> #info This is determined in a few ways:
17:08:20 * tflink is around
17:08:20 <jreznik> #info No remaining blocker bugs
17:08:22 <jreznik> #info Release candidate compose is available
17:08:23 <jreznik> #info Test matrices for Beta are fully completed
17:08:25 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist
17:08:26 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC3_Installation
17:08:28 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC3_Base
17:08:29 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC3_Desktop
17:08:31 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC3_Server
17:08:32 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC3_Cloud
17:08:46 <jreznik> moving on
17:08:48 <jreznik> #topic Current status
17:08:51 <adamw> hmm? we have outstanding proposed blockers, I think.
17:09:20 <jreznik> ?
17:09:32 <nirik> one
17:09:34 <adamw> well, one.
17:09:37 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1211887
17:10:11 * satellit sawit on update-reboot in rc3 workstatio today
17:10:33 <jreznik> #info we have one outstanding proposed blocker
17:10:35 * satellit entry works
17:10:43 <adamw> -1, the affected grubby isn't in rc3.
17:10:46 <nirik> -1
17:10:48 <jreznik> #info latest release candidate is RC3
17:10:52 <nirik> can be fixed in updates.
17:10:54 <sgallagh> -1
17:10:57 <jreznik> you're too fast today!
17:11:00 <adamw> https://dl.fedoraproject.org/pub/alt/stage/22_Beta_RC3/Workstation/x86_64/os/Packages/g/
17:11:01 <nirik> also cosmetic
17:11:06 <adamw> grubby-8.35-9.fc22.x86_64.rpm
17:11:18 <jreznik> but ok, we can do it in this section if you insist (or I'm just too slow today)
17:11:21 <kparal> it affected netinst, though
17:11:32 <adamw> kparal: it won't soon.
17:11:35 <kparal> but seems unpushed
17:11:41 <nirik> it just means the menu entry is garbage... but it still boots and works fine.
17:11:45 <adamw> kparal: the affected grubby has already been pulled and replaced with one which ought to be fixed
17:11:54 <kparal> ok, -1
17:12:01 <jreznik> -1
17:12:03 <adamw> nirik: problem is that all subsequent menu entries will be garbage until you manually fix the top one, which is a shame - we should send out an email. but no need to hold beta.
17:12:24 <nirik> sure. but only for those brave testers that got the bad one.
17:12:25 <jreznik> anyone from QA wants to do that nice rejected blocker proposal? :)
17:12:55 <adamw> propose #agreed - 1211887 - RejectedBlocker: the affected grubby is not in the RC3 package set (and never made it out of updates-testing)
17:13:03 <nirik> ack
17:13:09 <jreznik> ack
17:13:16 <jreznik> btw thanks adamw :)
17:13:23 * satellit ack
17:13:32 <adamw> #agreed - 1211887 - RejectedBlocker: the affected grubby is not in the RC3 package set (and never made it out of updates-testing)
17:14:22 <jreznik> ok, is there anything else to discuss for the current status?
17:14:35 <jreznik> #info proposed blocker was rejected as the beta blocker bug
17:14:38 * danofsatx is here, phone rang
17:15:13 <jreznik> as otherwise I'll skip mini blocker review section as we did it already here
17:15:32 <jreznik> so anything else that needs discussion before moving on to QA coverage?
17:15:45 <adamw> let's see
17:16:05 <adamw> there's the fedup keyboard layout blocker: just to note that's a 'special blocker' which requires an f21 update
17:16:29 <adamw> we also have some issues with liveusb-creator on f21 which we can discuss or just kick under the carpet...
17:16:54 * danofsatx lifts up the corner of the carpet
17:17:14 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1166650
17:17:28 <jreznik> I don't have any carpets at home...
17:17:37 <adamw> (it's also busted on f22 with some kind of qt/X interaction that's also affecting hp-plugin, but i don't think anyone cares too much about that case)
17:18:11 <satellit> worked for me
17:18:21 <satellit> except for (cp)
17:18:24 <adamw> the criterion we have, precisely, is:
17:18:26 <adamw> "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods."
17:18:38 <adamw> where 'officially supported methods' is a link to https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB
17:18:52 <jreznik> adamw: for that qt/x I'm not sure it's issue - that error is sometimes pretty frequent and app works (as I remember, it might be something else)
17:19:01 <adamw> it's really supposed to ensure the images are properly built for writing to USB, which i don't think is an issue.
17:19:01 <nirik> right, so _any_ not _all_ ?
17:19:26 <adamw> nirik: no, in this case 'any' means 'all' linguistically. though i think i meant to change that to clarify it. anyhoo, it's meant to mean 'all'.
17:19:33 <nirik> ok
17:19:43 <adamw> for alpha it says 'at least one'
17:20:25 <jreznik> so let's say fot beta 'most' and final 'all' but I still think 'all' should be in ideal world 1 official method
17:20:46 <adamw> so there's kind of a question whether luc itself having issues in f21 violates that. still, the bug isn't a complete showstopper, just needs you to try twice, and we can fix it with an f21 update. we're not aware of any issues in the rc3 images themselves relating to usb writing.
17:21:13 <nirik> yeah, seems like we can go and work on fixing that ongoing
17:21:14 <jreznik> in such case as described above, I'd say -1
17:21:20 <adamw> that's not a fudge, btw, we really *have* had cases where the images themselves wouldn't boot when written to USB for one reason or another, and that's by far the more serious issue
17:21:28 <adamw> (and the reason we wrote the criterion)
17:21:50 <adamw> still, wanted to bring it up here in case anyone thought it was a major issue.
17:22:27 <jreznik> sure
17:22:27 * kparal is fine with -1 for Beta
17:22:57 <sgallagh> adamw: There's also an odd issue with live media not verifying on UEFI boot, but that's a Final criterion. (The verification is broken, not the media)
17:23:26 <dgilmore> sgallagh: I think that may have been the case for a few releases
17:23:53 <sgallagh> dgilmore: Then we should either fix it or not have media-check be the default boot target.
17:24:13 <kalev> or both? :)
17:24:18 <adamw> or yak farm!
17:24:25 <danofsatx> +1 both
17:24:27 * jreznik votes for yak farm
17:24:46 <sgallagh> /me *did* use OR, not XOR.
17:25:27 <jreznik> but it seems like the agreement is in favor of the issue brought up above are not blocking issues, right?
17:25:27 <danofsatx> either implies XOR
17:25:43 <adamw> jreznik: yeah. we don't need a formal vote as it's not proposed
17:26:17 * adamw was also stalling for time while he runs some more tests. :P
17:26:23 <sgallagh> Nothing to see here, move along :)
17:26:37 <jreznik> #info the other issues brought up on the go/no-go meeting were not considered serious enough to be proposed as blocker bugs
17:26:59 <sgallagh> \o/
17:27:00 <jreznik> moving on
17:27:02 <jreznik> #topic Test Matrices coverage
17:28:08 <jreznik> so, where we are with the QA coverage? what's still missing?
17:28:14 <jreznik> I see ARM being filled in
17:28:33 * adamw working through it
17:28:42 <danofsatx> fedup and nfs tests are missing
17:28:43 <jreznik> ok
17:29:07 <danofsatx> looks like no server tests are done
17:29:07 <kparal> don't forget to refresh
17:29:30 * danofsatx makes sure he's looking at the right page
17:29:42 <adamw> we're basically not expecting all tests to be run with rc3
17:29:50 <adamw> as it was very late notice and only PackageKit changed
17:29:50 <sgallagh> danofsatx: All of the server tests were completed on RC2 and should carry over, since only one package was changed.
17:29:50 <pwhalen> jreznik, working on arm, please let me know if there is something that needs coverage. most were done with RC2
17:30:02 <danofsatx> roger
17:30:05 <adamw> we wanted to make sure sanity tests were done and pacakgekit-affected tests (so, GNOME and KDE update tests) were re-done
17:30:17 <sgallagh> FWIW, I have spot-checked a few things on Server RC3 as well and nothing is visibly broken
17:30:22 <adamw> i am transferring over results from rc2 for other tests, done Installation, not done the other pages yet
17:30:59 <danofsatx> fedup wasn't done on RC2, either
17:31:13 * danofsatx prepares an F21 VM
17:31:14 <jreznik> adamw: KDE wasn't broken in RC2 but with change under the hood I understand
17:31:20 <adamw> danofsatx: yes, so I re-did minimal with rc3 and transferred the other results from rc1
17:31:32 <adamw> jreznik: right, for KDE it's to make sure we didn't bust anything.
17:31:37 <satellit> adamw RC3 Workstation worked  KDE need updater turned on then it works
17:31:55 <danofsatx> ok, I'll go back to 1 then
17:32:13 <adamw> so basically the matrix status is: everyone please talk about yak farm plans for 15 minutes while we finish up fudging them, nothing to see here. :P
17:32:30 <jwb> if there's a lul, i have a question/comment
17:32:37 <adamw> go for it.
17:32:50 <jwb> so there's a bug in the kernel that is causing livecds to boot very slowly
17:33:07 <danofsatx> so, what is ~20 acres going for in Colorado these days?
17:33:08 <jwb> on SMP configurations.  it boots, but the impression on gets isn't wonderful
17:33:14 <adamw> oh, that one.
17:33:17 <jwb> yes.
17:33:24 <jwb> jforbes is digging into it
17:33:26 <adamw> got a bit lost in the shuffle i think :/
17:33:32 <tflink> danofsatx: depends on which part of colorado
17:33:40 <adamw> jwb: it was reported on KVMs, right? how bad is it on metal?
17:34:08 <satellit> USB boot of lives is not that slow
17:34:10 <jwb> not sure, but it's present on bare metal in SMP too when you run a live image.  i don't think it's blocker, but we might want to make sure to point out live images should maybe be booted with maxcpus=1 until we figure it out
17:34:15 <danofsatx> I'd like my own mountain, but the missus doesn't like much snow so it would have to be the eastern plains, I guess. I'm not sure what kind of terrain yaks prefer, though, so she might get outvoted.
17:34:24 <adamw> satellit: on a multi-CPU system?
17:34:35 <jwb> satellit, yeah, it isn't unbearably slow.  but it's slower than it should be.
17:34:39 <adamw> jwb: add CommonBugs to the keyword field for the bug
17:34:45 <kparal> jwb: I have noticed that there were like 30+ kworker processes shown in top during anaconda install, not sure whether it is expected or not
17:35:05 <jreznik> yep, good thing for commonbugs
17:35:07 <jwb> kparal, there's over 200 kworkers and then it eventually goes down
17:35:12 <satellit> YogaPro2 and bios boot on MSI windbox wich has 2 I think
17:35:53 <sgallagh> That's odd, because I've been noticing that my Server RC3 installs have been booting in record time.
17:36:02 <sgallagh> (in multi-core VMs)
17:36:15 <sgallagh> They're spending longer in the BIOS boot than in dracut.
17:36:24 <gary_buhrmaster> danofsatx: I suspect free range yaks will need more then 20 acres.
17:36:29 <adamw> sgallagh: jwb said lives.
17:36:29 <jreznik> also DE lives are not that bad
17:36:36 <sgallagh> oh, my mistake
17:36:39 <jreznik> in VM with more cores
17:37:01 <kparal> jwb: ok. do you happen to have a bug number?
17:37:14 <danofsatx> Oh, I missed a 0. It was supposed to be 200.
17:37:39 <jwb> kparal, sec
17:37:54 <jwb> 1210857
17:38:02 <jwb> jreznik, DE?
17:38:07 <jwb> (sorry, in multiple meetings)
17:38:13 <jreznik> desktops
17:38:16 <adamw> no-one's done Base tests for cloud in any RC
17:38:18 <nirik> .bug 1210857
17:38:20 <adamw> can anyone knock those off?
17:38:21 <zodbot> nirik: Bug 1210857 Very slow boot on multicore - https://bugzilla.redhat.com/1210857
17:38:55 <nirik> adamw: I thought I did... or perhaps I added my results to the wrong place?
17:38:57 <kparal> nirik: thanks
17:39:02 <adamw> nirik: i don't see any
17:39:06 <adamw> nirik: where did you file?
17:39:28 <jwb> jreznik, i've been booting the workstation live images.  it's definitely noticable there
17:39:43 <nirik> https://fedoraproject.org/w/index.php?title=Test_Results:Fedora_22_Beta_RC3_Cloud&diff=prev&oldid=410268 ?
17:39:49 <nirik> or is base another set of things?
17:39:56 <jwb> jreznik, and the bug reporter noticed it because of workstation live in boxes
17:40:16 <adamw> nirik: base is another page
17:40:21 <adamw> nirik: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC3_Base
17:40:36 <adamw> oh
17:40:41 <adamw> we're actually duplicating things there.
17:40:58 <adamw> so we probably just need to drop the cloud column from the Base page, let's call it covered.
17:41:01 <nirik> yeah, thats the same ones I did.
17:41:01 <kparal> we need just those Alpha ones
17:41:06 * satellit boxes 3.16.0 seems fast on boot for me in f22 on mate live install
17:45:51 <adamw> ok, i'm just about done fudging the matrices
17:46:02 <adamw> we're missing audio_basic for KDE...that's about it
17:46:16 <adamw> had to pull a few from RC1, but i'd say we have pretty good coverage. the rc1/rc2 delta was fairly small also.
17:47:03 <jreznik> adamw: automount, not audio
17:47:03 <adamw> gah, anyone have hardware RAID setup lying around?
17:47:11 <adamw> jreznik: sorry, audio_basic for KDE ARM
17:47:16 <adamw> automount i pulled in from rc1
17:47:22 <jreznik> aha, ok
17:47:27 * adamw really doesn't want to start yanking disk cables.
17:47:51 <satellit> some lives require mount from file manager but see the USB
17:48:45 <adamw> satellit: for automount? that's fine if it's how the desktop wants to do it
17:48:51 <satellit> k
17:48:54 <adamw> it doesn't literally have to *mount* it immediately, just make it available to the user
17:49:58 <adamw> so yeah, we're missing hw raid (which i'm like 99% sure is fine), and audio for ARM, that's about it.
17:50:51 <sgallagh> adamw: So is QA therefore comfortable with the coverage?
17:51:01 <adamw> oh, also missing SAS because, christ, SAS.
17:51:44 <jreznik> pwhalen: could you pls try audio basic on ARM (and turn your speaker loud enough so adamw will hear it)
17:51:50 <adamw> strictly speaking we ought to have everything
17:52:00 <sgallagh> adamw: Considering we keep handwaving SAS, can we just vote to remove it from the criteria?
17:52:03 * adamw really ought to go buy an HW raid adapter for his test box.
17:52:03 <jreznik> but I expect it should not be an issue... and if, it would be more hw issue
17:52:08 <adamw> sgallagh: we probably should.
17:52:24 <pwhalen> jreznik, sadly this hw lacks audio.. checking another
17:52:26 <adamw> jreznik: yeah, i think we can say the x86 test is OK there.
17:52:28 <sgallagh> Proposal: remove SAS from release criteria
17:52:36 <adamw> sgallagh: let me try and word that a bit better. :P
17:52:40 <jreznik> pwhalen: I thought it's HW :)
17:52:42 <sgallagh> By all means
17:53:07 <jreznik> pwhalen: so I'd say np, it should work if HW is available
17:53:08 <adamw> let's see, the criterion says "The installer must be able to complete an installation using any supported locally connected storage interface."
17:53:21 <adamw> i suggest instead we mark the test as Optional, with a note in the test that it's optional because the hardware is so rare.
17:53:32 <adamw> but if you actually run it and it fails, make it a blocker.
17:53:52 <jreznik> and do we really want it as blocker if it's so rare?
17:53:56 <adamw> meh.
17:54:00 <adamw> i dunno, i want a yak.
17:54:07 <adamw> i guess we might handwave it.
17:54:50 * nirik could possibly scare up hw to run that test on, but not right this second.
17:56:26 <kparal> it's the same story every release, I say we nuke the test case from orbit
17:56:51 <sgallagh> It's the only way to be sure
17:57:18 <adamw> heh
17:57:46 <adamw> ok, modification: stick 'commonly-used' in the criterion.
17:58:05 <adamw> and am I really the only one with an hw raid controller? sigh.
17:58:28 <jreznik> commonly used might work (I can see fights what's commonly used but)
17:58:48 <jreznik> adamw: everyone has laptops :)
17:58:53 <kparal> +1
17:58:55 <sgallagh> I think making it subjective like that would be a good idea. It allows us to more easily make judgement calls
17:59:23 * adamw still doesn't really like judgement calls, but it seems slightly unavoidable
17:59:26 <nirik> hw raid is horrible. ;)
17:59:35 <adamw> the alternative is a specific list of interfaces that we update every time someone invents a new one or whatever
17:59:38 <sgallagh> adamw: Just get better judgement ;-)
17:59:41 <adamw> =)
18:00:25 <adamw> jesus, so apprently we've not done hw raid once for 22.
18:00:35 <adamw> fiiiine, everyone talk about yak farms some more while i fumble about under my desk and curse.
18:01:58 <jwb> given the set of commits we've narrowed down the live image bug to, that kind of makes me afrai
18:02:01 <jwb> d
18:02:33 <sgallagh> jwb: Sorry, I think I missed some context for that last statement
18:03:09 <jwb> sgallagh, the fact that nobody has tested hw raid
18:03:34 <sgallagh> And the set of commits you've narrowed it down to are hwraid related?
18:03:38 <jwb> the "slow boot" bug has been narrowed down to the merge of the dm and block layer commits in the kernel
18:03:43 <sgallagh> ahhh
18:03:50 <adamw> ....awesome.
18:04:01 <adamw> well, we'll find out just as soon as i figure out which goddamn sata connector is plugged to where.
18:04:24 <jwb> adamw, oddly enough, we had another set of issues a while ago in the same range but then you found the dracut thing that was causing havoc and the kernel issue fell by the wayside
18:04:26 <sgallagh> So when we talk about hwraid, are we discussing LSI or something else?
18:05:05 <danofsatx> I can have an Intel on-board RAID test, and an HP SAS RAID, but not today.
18:05:46 * danofsatx makes a note to start testing that in the future
18:07:25 <adamw> intel onboard is firmware raid
18:07:28 <adamw> we already did that
18:07:34 <adamw> it's true *hardware* raid we haven't done
18:07:58 <jwb> that might be a bit less scary
18:08:01 <jwb> (to me)
18:08:21 <danofsatx> ok, that would be my HP cards, then.
18:08:55 <danofsatx> I've got Proliant DL365 and DL385 servers in the back.
18:10:27 <jreznik> so anyone is going to take a look on it or fudge it and go yaks?
18:10:36 <adamw> i'm doing i
18:15:36 <adamw> looks good so far
18:17:00 <adamw> https://www.happyassassin.net/temp/hwraid.jpg <--- HIGHLY PROFESSIONAL TESTER AT WORK
18:17:25 <adamw> (yes, they are sitting on an upturned shoulder bag because the sata power cable does go far enough for them to sit on the floor like they would in a real pro's test rig.)
18:17:32 <danofsatx> izzat a dog turd in the corner?
18:18:08 <adamw> unless a dog snuck in here while i wasn't looking...i'm pretty sure not.
18:18:17 <jreznik> it's called creative tester at work
18:18:47 <danofsatx> I would set them on top of the case, myself....
18:18:54 <juliuxpigface> your case is probably whining about dust :)
18:18:55 <adamw> danofsatx: doesn't reach far enough for that either.
18:19:20 <adamw> i mean, they would if i re-routed them, but srsly who has the time
18:19:27 <adamw> installing boot loader...
18:19:44 <danofsatx> obvsly not you, since you don't have time to type seriously
18:19:50 <adamw> inorite
18:20:14 <adamw> if you ever need cheering up just sound out 'srsly' to youself. it's the most fun thing ever.
18:21:07 <dgilmore> for realz?
18:21:10 <adamw> ok, hwraid is go
18:21:12 <adamw> 4REALZ
18:21:28 <jreznik> ooo
18:21:38 <danofsatx> proposal: all future meetings to be held in LOLZCAT language only
18:21:58 <jreznik> it isn't now?
18:22:04 <adamw> u can haz +1
18:22:21 <jreznik> so we can say, qa coverage is g00d now?
18:22:27 <adamw> i beliebe so!
18:23:10 <adamw> any qa folks disagree?
18:23:44 * danofsatx wanders off into the cheezburger hole.....
18:23:48 <jreznik> seems like not, moving on
18:23:51 <jreznik> #info QA coverage is good
18:23:56 * kparal agrees
18:24:03 <jreznik> #topic Go/No-Go decision
18:24:43 <jreznik> we're here! adamw, nirik, sgallagh, dgilmore and others!
18:24:58 <nirik> After careful and calm pondering, and with all due seriousness, I should like to state that I think we are, in fact, today, go.
18:25:32 <jreznik> that's not LOLZCAT
18:25:52 <adamw> no outstanding blockers, sufficient test coverage == QA votes GO
18:25:53 <sgallagh> With great solemnity, I deem RC3 worth visiting upon an unsuspecting populace.
18:26:04 <adamw> sgallagh: they'll never know what hit 'em.
18:26:07 <kalev> AFTR CAREFUL AN CALM PONDERIN, AN WIF ALL DUE SERIOUSNES, I SHUD LIEK 2 STATE DAT I FINKZ WE R, IN FACT, TODAI, GO.
18:26:57 <jreznik> http://harmonichvac.com/wp-content/uploads/2013/12/oh-no.jpg
18:27:15 <jreznik> dgilmore: are you around?
18:28:28 <dgilmore> jreznik: yeah
18:28:39 * danofsatx counts that as a go
18:28:40 <jreznik> are you go?
18:28:47 <dgilmore> jreznik: yes we are go
18:28:54 <jreznik> danofsatx: that's also an option :)
18:29:05 <jreznik> proposal #agreed Fedora 22 Beta status is go by Release Engineering, QA and Development
18:29:19 <sgallagh> ack
18:29:20 <nirik> ack
18:29:54 <jreznik> one more ack to go ;)
18:29:57 <kalev> ack!
18:30:15 <kparal> ack
18:30:24 <jreznik> #agreed Fedora 22 Beta status is go by Release Engineering, QA and Development
18:30:48 <adamw> wheee
18:30:48 <jreznik> T+30 minutes and we're Go :) thanks everyone!
18:31:49 <jreznik> #topic Open floor
18:31:56 <jreznik> anything for open floor?
18:32:11 * jreznik is going to announce go decision
18:32:45 <sgallagh> Well done, folks!
18:32:54 <pwhalen> \o/
18:32:59 <sgallagh> We remain only one week slipped from the original schedule. Let's keep it that way for Final, yeah?
18:33:23 <kalev> I did my part yesterday, fixing that last blocker :)
18:33:46 <sgallagh> /me notes https://qa.fedoraproject.org/blockerbugs/milestone/22/final/buglist
18:33:48 <jreznik> kalev: you rock!
18:34:16 <danofsatx> eek!
18:34:46 <jreznik> setting fuse... 3...
18:35:51 <jreznik> 2...
18:36:38 <jreznik> 1...
18:36:47 <jreznik> thank you everyone for coming!
18:36:52 <jreznik> #endmeeting