17:01:06 <jreznik> #startmeeting F19 Beta Go/No-Go meeting
17:01:06 <zodbot> Meeting started Thu May 23 17:01:06 2013 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:16 <jreznik> #meetingname F19 Beta Go/No-Go meeting
17:01:16 <zodbot> The meeting name has been set to 'f19_beta_go/no-go_meeting'
17:01:33 <jreznik> #topic Roll Call
17:01:59 <adamw> ahoy hoy
17:02:01 <jreznik> hey!
17:02:07 <tflink> whee!
17:02:08 * satellit listening
17:02:17 <jreznik> adamw: ahoj is the correct way here to write :)
17:02:22 <jreznik> it
17:02:26 <Viking-Ice> mja
17:02:31 <adamw> that's not how mr. burns says it
17:02:49 <jreznik> #chair adamw tflink rbergeron
17:02:49 <zodbot> Current chairs: adamw jreznik rbergeron tflink
17:03:22 * nirik waves
17:03:52 * jreznik is going to skip waiting too long for people joining to save adamw
17:04:00 <adamw> heh, it's okay.
17:04:01 <adamw> but thanks
17:04:42 <jreznik> #topic Purpose of this meeting
17:04:44 <jreznik> #info Purpose of this meeting is to see whether or not F19 Beta is ready for shipment, according to the release criteria.
17:04:46 <jreznik> #info This is determined in a few ways:
17:04:47 <jreznik> #info No remaining blocker bugs
17:04:49 <jreznik> #info Test matrices for Beta are fully completed
17:04:50 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/19/beta/buglist
17:04:52 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Beta_RC4_Install
17:04:53 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Beta_RC4_Base
17:04:55 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_19_Beta_RC4_Desktop
17:04:56 <jreznik> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria
17:05:45 <jreznik> let's start with blocker review
17:05:54 <jreznik> #topic blocker review
17:05:56 * rbergeron rolls in late, sorry
17:06:02 <tflink> #info Up for review today, we have:
17:06:04 <jreznik> tflink: may I ask you to lead it?
17:06:08 <jreznik> ah, thanks
17:06:10 <tflink> #info 4 Proposed Blockers
17:06:10 <tflink> #info 2 Accepted Blockers
17:06:26 <tflink> starting with the proposed blockers ...
17:06:32 <tflink> #topic (959677) IndexError: list index out of range
17:06:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=959677
17:06:33 <tflink> #info Proposed Blocker, anaconda, NEW
17:07:16 <tflink> my understanding is that this is limited to litd created usb install media and not selecting any disks on the storage spoke
17:07:23 <adamw> so, this one happens when you're running from a litd-created USB stick and you de-select all available disks in the disk picker, as far as we know
17:07:34 <tflink> we have -2 blocker in gut already
17:07:36 <adamw> there might be some other trigger, but that's the one we know
17:07:38 <tflink> in bug
17:07:50 <jreznik> based on data provided in bug, I'm -1 blocker and needs a specific action to be taken
17:07:52 * tflink is also -1
17:08:03 * rbergeron is -1 as well
17:08:05 * nirik is -1
17:08:12 <adamw> jreznik: it is true that the action is more likely to be taken due to a ui issue
17:08:47 <adamw> the check mark that indicates a disk is selected doesn't really jump out at you, it seems quite common for people to get disk selection 'wrong' with the current ui. but still not serious enough to block for, i don't think
17:08:49 <jreznik> adamw: it is but could be documented - as I said in the bug, but ui should be tweaked later
17:08:53 <adamw> yeah
17:09:11 <tflink> proposed #agreed 959677 - RejectedBlocker - While this is not good, it is limited to a specific type of install media and a specific action within the installer UI that users are not likely to do. Rebooting at that point in the install does not cause data loss and thus this is deemed to not be a blocker for F19 beta
17:09:23 <tflink> ack/nak/patch?
17:09:25 <adamw> ack
17:09:27 <rbergeron> ack
17:09:30 <jreznik> ack
17:09:47 * adamw will secretaryalize
17:09:53 <tflink> #agreed 959677 - RejectedBlocker - While this is not good, it is limited to a specific type of install media and a specific action within the installer UI that users are not likely to do. Rebooting at that point in the install does not cause data loss and thus this is deemed to not be a blocker for F19 beta
17:09:58 <tflink> adamw: thanks
17:10:06 <tflink> #topic (966598) Crash in VG creation when installing LVM-on-Intel firmware RAID (19 Beta RC4)
17:10:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966598
17:10:12 <tflink> #info Proposed Blocker, anaconda, NEW
17:11:03 <tflink> adamw would know more but from the conversation in #anaconda, it sounds like this is an issue with pre-existing but incomplete metadata on the target disks
17:12:29 <adamw> yeah, now it seems this relates to some data that happened to be lying about on one of the disks in my array i'm even less concerned about it
17:12:47 <Viking-Ice> well rest of votes
17:12:58 <adamw> it's the kind of thing people might conceivably hit, but it's always going to be a bit of a crapshoot when you create raid arrays out of previously-populated disks
17:13:10 <nirik> -1 blocker, document.
17:13:15 * tflink is -1 blocker, this feels similar to the problem you run into when trying to re-use one disk from a sw raid set
17:13:19 <jreznik> -1 blocker
17:13:24 <nirik> (for all small number of people that use that :)
17:13:24 <adamw> tflink: it's kinda along those lines, yeah.
17:13:56 <adamw> so, -1
17:14:21 <jreznik> Viking-Ice already voted in bug, -1
17:14:54 <tflink> proposed #agreed 966598 - RejectedBlocker - This does cause problems during install but it is limited to specific cases of re-using disks that have existing metadata from old installs. As such, it is too much of a corner case to block release and is rejected as a blocker for F19 beta
17:14:59 <nirik> ack
17:15:25 <rbergeron> ack
17:15:27 <jreznik> ack
17:15:37 <Viking-Ice> ack
17:15:49 <tflink> #agreed 966598 - RejectedBlocker - This does cause problems during install but it is limited to specific cases of re-using disks that have existing metadata from old installs. As such, it is too much of a corner case to block release and is rejected as a blocker for F19 beta
17:15:59 <tflink> #topic (966586) System doesn't boot after upgrade on UEFI
17:15:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966586
17:15:59 <tflink> #info Proposed Blocker, fedup, NEW
17:17:09 <tflink> this is related to a bug we had @ alpha where grub2 doesn't work on uefi systems when in graphical mode
17:17:32 <tflink> F18 uefi is installed in graphical mode and the grub cfg is not modified during upgrade
17:17:39 <adamw> so with this one a more important question than 'is it a blocker?' is 'do we have to fix it in the frozen package set'?
17:17:43 <nirik> so, is there a manual work around?
17:17:45 <adamw> to which we're pretty sure the answer is 'no'
17:17:53 <tflink> nirik: change the grub.cfg to use console
17:17:57 <adamw> yes, there is a manual work around, and we are quite sure this can be fixed just by updating the repos
17:17:58 <nirik> yeah.
17:18:07 <jreznik> and could be workarounded as kparal verified and it could be fixed out of the frozen package set
17:18:10 <adamw> kparal tested that switching to console mode grub before doing the fedup (or, probably, after) works as a workaround
17:18:22 <Viking-Ice> can we confirm this can be fixed via update in repo
17:18:36 <Viking-Ice> as in the method works not the actual fix part
17:18:40 <adamw> so we can call this a 'special case' blocker (like bugs in preupgrade used to be) or just -1 it, but it seems pretty clear we don't need to respin or slip for it.
17:18:40 <tflink> before would be better than after
17:18:48 <adamw> well, easier
17:18:56 <tflink> you have to boot into rescue mode or some equivalent to fix it post-upgrade
17:19:08 <tflink> true, the effect is the same
17:19:29 <nirik> yeah. -1 blocker, fix in repo if possible before release, document if not?
17:19:35 <adamw> Viking-Ice: the only way to confirm 100% is to actually test it
17:19:51 <adamw> Viking-Ice: but given what we know at this point i'd say it's about 99% certain that just sending out an updated grub2 to the repos will fix this
17:20:15 <jreznik> and in case it would not work, there's possibility of manual intervention - document
17:20:27 <adamw> we just need to make sure that happens; i asked pjones to do it, if he's too busy i'll do it in a day or two
17:20:28 <tflink> and otherwise, we can document the console setting and write up a fix for if/when people don't read the docs prior to upgrading
17:20:35 <adamw> the build exists in koji, it just needs to be pushed as an update
17:20:38 <adamw> right
17:20:40 <nirik> cool.
17:20:41 <Viking-Ice> well we are forced to officially support upgrading so we should be -1 based on criteria
17:20:45 <tflink> I see +1 from bug
17:20:59 <Viking-Ice> mean +1
17:21:03 <adamw> and as viking pointed out in the bug, it's not like upgrades have ever been a sure thing anyways
17:21:18 <tflink> I'm probably closer to -1
17:21:20 <adamw> Viking-Ice: well, there's a bit of wiggle room since this only affects UEFI
17:21:25 <Viking-Ice> yeah and we cant support it seriously we cant best effort is even stretching that support
17:21:35 <adamw> Viking-Ice: we can say UEFI upgrades are a small fraction of all upgrades so upgrade is working well enough, -1
17:21:49 <adamw> it's a bit of a fudge, but it's kinda academic anyway...
17:21:56 <tflink> so +1/-3 so far
17:22:02 <tflink> any other votes?
17:22:17 <Viking-Ice> I myself is -1 but forced to be +1 due to "official" labeling
17:22:19 <adamw> i guess i'll vote with the majority just to move things along, though i take viking's reasoning for +1
17:22:34 <adamw> Viking-Ice: you can use my fudge :)
17:22:41 <jreznik> -1 as it seems to be covered and start the discussion how to deal it on list
17:23:00 <adamw> the criterion says "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed."
17:23:12 <adamw> it certainly *is* possible to do that - just so long as the installation is a BIOS one not a UEFI one. :P
17:23:22 <nirik> or if you manually work around this on efi
17:23:25 <adamw> right.
17:23:34 <jreznik> and we hope nicer fix would work too
17:23:37 <adamw> but yeah, i really should quit twisting the criteria i wrote into pretzels.
17:23:43 <adamw> *slaps own hand*
17:24:21 <tflink> and it is possible to do an upgrade with manual intervention
17:24:29 <adamw> so, mine's a -1, makes it +1/-5?
17:24:41 <tflink> it's not like the system is completely broken, it is fixable without too much effort
17:24:56 <tflink> if this was final, I'd be less -1
17:24:58 <adamw> true. it's not such a horrible fudge to say this isn't a blocker, i guess
17:25:25 <jreznik> yep, let's move on
17:26:56 <tflink> proposed #agreed 966586 - RejectedBlocker - While this does have a negative impact on upgrades for UEFI systems, it is workaround-able and doesn't result in a system which can't be reasonably fixed. An updated grub2 package should fix this but even if it doesn't, the workarounds will be documented. Rejected as a release blocking bug for F19 beta.
17:27:01 <tflink> ack/nak/patch?
17:27:17 <Viking-Ice> fudge ack
17:27:29 <nirik> acky
17:27:50 <jreznik> ack
17:28:53 <adamw> ack
17:28:55 <tflink> #agreed 966586 - RejectedBlocker - While this does have a negative impact on upgrades for UEFI systems, it is workaround-able and doesn't result in a system which can't be reasonably fixed. An updated grub2 package should fix this but even if it doesn't, the workarounds will be documented. Rejected as a release blocking bug for F19 beta.
17:29:06 <tflink> #topic (957783) fedup from F18 -> F19 hangs at reboot
17:29:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=957783
17:29:06 <tflink> #info Proposed Blocker, systemd, NEW
17:29:26 <tflink> is this happening on non-ppc systems?
17:29:56 <adamw> i dunno, but even if it is, it's not a blocker.
17:29:57 <tflink> as I read it, this is a problem with the system rebooting post-upgrade
17:30:21 <tflink> the upgrade completes with a nasty-looking crash at the end but the upgraded system works fine after a manual reboot
17:30:42 <nirik> -1 blocker.
17:30:49 <tflink> I see -3 blocker in bug
17:30:56 <jreznik> -1 beta blocker
17:30:57 * tflink is also -1, making for -5
17:30:59 <tflink> -6
17:32:36 <tflink> proposed #agreed 957783 - RejectedBlocker - While this is a nasty looking bug, it does not actually interfere with the upgrade process beyond requiring a manual reboot post-upgrade. As such, it was judged not to be severe enough to block release and is rejected as a release blocking bug for F19 beta.
17:32:41 <tflink> ack/nak/patch?
17:32:59 <jreznik> ack
17:33:22 <Viking-Ice> ack
17:33:27 <adamw> ack
17:33:41 <tflink> #agreed 957783 - RejectedBlocker - While this is a nasty looking bug, it does not actually interfere with the upgrade process beyond requiring a manual reboot post-upgrade. As such, it was judged not to be severe enough to block release and is rejected as a release blocking bug for F19 beta.
17:33:52 <tflink> OK, that's all of the proposed blockers on my list
17:34:05 <tflink> we have 2 accepted blockers which haven't been closed yet, but they're both VERIFIED
17:34:22 <tflink> do we want to review them for the sake of completeness?
17:35:07 <adamw> sure, why not, it'll be quick.
17:35:25 <tflink> #topic (964069) Anaconda creates native partition in text mode if LVM or btrfs is selected
17:35:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=964069
17:35:25 <tflink> #info Accepted Blocker, anaconda, VERIFIED
17:36:09 <tflink> this was an issue where the partition type couldn't be changed in text mode
17:36:54 <tflink> #info 964069 was confirmed as fixed with F19 beta RC3
17:37:08 <tflink> anything else to bring up on this bug?
17:37:17 <jreznik> no
17:37:20 <adamw> i'm just double checking it's fixed in rc4
17:37:51 <tflink> IIRC, it worked in my smoke image text-install text last night but I wasn't looking for partition types
17:38:03 <tflink> and that wouldn't be confirmation anyways
17:38:17 <adamw> confirmed, i just told it to create btrfs, and it did.
17:38:23 <tflink> awesome
17:38:27 <tflink> moving on
17:38:32 <tflink> #topic (966162) fedora-dmraid-activate shouldn't tell kpartx to use a partition delimiter
17:38:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966162
17:38:37 <tflink> #info Accepted Blocker, dmraid, VERIFIED
17:38:45 <tflink> this was a fun bug that was preventing install to dmraid arays
17:38:47 <adamw> and tim tested this a few hours ago.
17:39:09 <nirik> cool.
17:39:31 <tflink> #info 966162 was verified as fixed in F19 beta RC4
17:39:56 <jreznik> great work adamw on this one!
17:39:57 * tflink assumes nothing else on this bug
17:40:17 <tflink> that is all of the proposed and accepted blockers on my list
17:40:26 <adamw> jreznik: eh, in the end i took six characters out of two packages
17:40:37 <adamw> jreznik: it was hardly mountain moving stuff :)
17:41:02 <adamw> yay for that
17:41:11 <jreznik> adamw: :)
17:41:15 <jreznik> tflink: thanks!
17:41:19 <tflink> np
17:41:36 <adamw> so that means we have: 0 accepted and unaddressed blockers
17:41:36 <jreznik> #info after blocker bug review, there are no accepted & unresolved blocker bugs
17:41:40 <adamw> whee
17:42:08 <jreznik> #topic Test matrices coverage
17:42:10 <nirik> hurray
17:42:36 <Viking-Ice> dont jinx it
17:42:39 <jreznik> adamw, tflink: ?
17:42:44 <adamw> test coverage is pretty much 100%
17:43:03 <Viking-Ice> where pretty is 30%?
17:43:09 <adamw> the damn uefi nvram exhaustion bug kinda cramped our efi testing a little bit, but i think we have enough passes from jskladan to be happy that it's working
17:43:19 <adamw> Viking-Ice: on alpha/beta tests, what's missing?
17:43:32 <Viking-Ice> adamw, an joke
17:43:37 <Viking-Ice> pretty much ;)
17:43:40 <adamw> ah :)
17:44:04 <jreznik> #info test matrices coverage is ok
17:44:38 <jreznik> let's go to the last step now everyone is waiting for :)
17:44:40 <adamw> every alpha/beta test is covered for at least one arch
17:44:51 <adamw> with only a couple of safe ones pulled from previous test runs
17:45:25 <jreznik> #info every alpha/beta test is covered for at least one arch, only couple of safe ones were pulled from previous test runs
17:45:38 <jreznik> #topic Go/No-Go decision
17:46:06 <jreznik> ok, here we are
17:46:46 <adamw> per QA's policy, as there are no accepted unaddressed blockers and test coverage is sufficient, QA votes "go"
17:46:51 <adamw> agreed, viking, tflink?
17:46:54 <tflink> agreed
17:47:01 <nirik> go go go. ;)
17:47:08 <jreznik> based on the blocker bugs status and test matrices coverage, Fedora Program Manager votes "go"
17:47:09 <Viking-Ice> agreed
17:47:42 <jreznik> rbergeron: ? as FPL
17:47:55 <jreznik> #info per QA's policy, as there are no accepted unaddressed blockers and test coverage is sufficient, QA votes "go"
17:48:11 <jreznik> #info based on the blocker bugs status and test matrices coverage, Fedora Program Manager votes "go"
17:49:08 <adamw> i guess rbergeron's busy
17:49:19 * jreznik thinks we do not have to wait for every ones Go as it's based on the policy
17:49:35 <jreznik> adamw: yep and I'd say, she would be the one to scream GO :)
17:49:50 <adamw> yeah, i think we can safely consider rbergeron a 'go'
17:49:59 <rbergeron> yes
17:50:14 <rbergeron> sorry - observing multiple ongoings ;)
17:50:32 <jreznik> #agreed Fedora 19 Beta is +1 to go by Fedora QA, FPL, FPGM and developers
17:50:43 <adamw> wheeee
17:50:44 * Viking-Ice dont let schrödinger's cat escape the beta bag
17:50:47 <adamw> great job everyone
17:50:47 <jreznik> rbergeron: np, I thought you would not ruin the party!
17:50:56 <jreznik> Viking-Ice: +1!
17:51:05 <jreznik> thank you guys!
17:51:19 <Viking-Ice> time to crack open a bottle of cheap wine and fry some delicious fedora beta bacon!!!
17:51:27 <adamw> sounds like a plan
17:51:34 <jreznik> and good night to adamw :)
17:51:39 * adamw is going to watch Strip Search and not look at his computer for a while
17:51:58 <jreznik> #topic open floor
17:52:34 <jreznik> the readiness meeting follows in approx. 1 hour - 19:00 UTC
17:53:11 * jreznik would be ok to get status from QA now and let them rest :)
17:53:30 <adamw> heh :) in case none of us shows up, our status is pretty good
17:53:37 <jreznik> adamw: thanks
17:53:48 <adamw> we need to write commonbugs as usual, i have a couple of things to throw in release notes, and we should take care of that grub2 update
17:53:56 <adamw> i can't think of much else beyond that we need to do before release
17:54:15 <jreznik> ok, I'll put it into meeting minutes in case no one will appear
17:54:37 * jreznik is setting tflink's patent encumbered random fuse now
17:55:05 <adamw> sue him!
17:55:40 <tflink> I'll be around
17:55:58 <tflink> preparing legal documents for upcoming patent violation lawsuit
17:56:04 <tflink> :)
17:56:20 <adamw> project colada lives
17:57:10 <rbergeron> mehooray
17:57:51 <jreznik> 3...
17:58:13 * jreznik is going to hire a lawyer
17:58:25 <jreznik> 2...
17:58:54 <jreznik> 1...
17:59:15 <jreznik> thank you again for coming and all the hard work on Beta - on time!
17:59:19 <jreznik> #endmeeting