19:00:27 <jreznik> #startmeeting F18 Final Go/No-Go meeting
19:00:27 <zodbot> Meeting started Wed Jan  9 19:00:27 2013 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:49 <jreznik> #meetingname F18 Final Go/No-Go meeting
19:00:49 <zodbot> The meeting name has been set to 'f18_final_go/no-go_meeting'
19:01:10 <jreznik> #topic Roll Call
19:01:25 * nirik is here.
19:01:33 * Viking-Ice is here
19:01:34 <jreznik> hey, who's here to see the release (hopefully)?
19:01:59 * pasik is here
19:02:01 <pjones> lots of people, it seems.
19:02:06 * tflink is here
19:02:44 * Martix is here
19:02:54 * jreznik hopes for lots of people :)
19:03:06 * sgallagh is here
19:03:51 <jreznik> let's wait a moment for more people to come
19:04:07 <drago01> .
19:04:27 * rbergeron pops in, sorry to be late
19:04:51 * rbergeron was procuring money for drinks at fudpub from a sponsor. so sorry :)
19:04:54 <jreznik> rbergeron: hi! we are about to start, on time!
19:05:02 <nirik> rbergeron: do not be sorry about that at all!
19:05:11 <jreznik> we will need a lot of drinks for fudcon...
19:06:12 <jreznik> #topic Purpose of this meeting
19:06:12 * adamw here
19:06:13 <jwb> i'm sort of here
19:06:19 <jreznik> #info Purpose of this meeting is to see whether or not F18 Final is ready for shipment, according to the release criteria.
19:06:24 <jreznik> #info This is determined in a few ways:
19:06:27 <adamw> tflink: can you ping konrad to join? you were chatting with him right?
19:06:30 <jreznik> #info No remaining blocker bugs
19:06:35 <jreznik> #info Test matrices for Final are fully completed
19:06:36 <tflink> adamw: yeah, will do
19:06:40 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist
19:06:44 <jreznik> #link http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
19:06:48 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Current_Base_Test
19:06:53 <jreznik> #link http://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
19:07:00 <jreznik> #link http://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
19:07:31 <jreznik> #topic current status
19:08:00 <adamw> so i'm just working on copying the rc2 matrices to rc3
19:08:07 <adamw> but for the purpose of this meeting, consider rc2 results to apply to rc3
19:08:28 <adamw> the only difference between rc2 and rc3 is the fedora-release-notes package being updated, which has approx 0.00001% chance of affecting any practical function
19:08:29 <Martix> what is rc4 status?
19:08:33 <jreznik> to clarify it - rc3 was created just for final release notes to be included
19:08:48 <jreznik> Martix: still not yet available
19:08:58 <adamw> we have done enough smoke tests of rc3 now to be confident nothing accidentally exploded between the two, so we can pretty much be happy rc3 is ok.
19:09:07 <adamw> dgil: made a mistake in the rc4 compose run, he's re-starting it
19:09:33 <jreznik> adamw: well, that's the reason why I'm scared from accepting anything else right now
19:09:36 <jreznik> any estimate?
19:09:50 <adamw> lives are done, dvd will be 1hr or so i guess.
19:10:23 <Martix> jreznik: yeah, much hurry produce mistakes
19:10:38 <jreznik> we can prolong this meeting in case we would need and we still have many to discuss before
19:11:18 <adamw> so anyway, for the purpose of considering current status, check the blocker list and rc2 matrices.
19:11:55 <adamw> for anyone unaware, rc4 is identical to rc3 except with updated fprintd to fix https://bugzilla.redhat.com/show_bug.cgi?id=810040 . that bug will likely form the main discussion for this meeting. we can choose to ship rc3 or rc4 depending on that decision (or do something else entirely, of course)
19:11:58 <jreznik> #info consider rc2 results to apply to rc3 as only the fedora-release-notes package was updated and after smoke testing there's confidence in functionality of rc3
19:12:40 <jreznik> #info rc4 is prepared right now for https://bugzilla.redhat.com/show_bug.cgi?id=810040 in case it will be needed
19:13:09 <jreznik> #info current status of rc4 - lives are done, dvd will be in 1 hours approx.
19:13:38 <jreznik> anything else to be added? btw. thanks adamw
19:14:22 <jreznik> let's start with blocker bugs review
19:14:22 <adamw> well, are we discussing the current status? :)
19:14:24 <adamw> okay
19:14:42 <pasik> adamw: I just got 20130109-prerc3-x86_64.iso download, so starting to test it..
19:14:51 <pasik> downloaded*
19:15:00 <jreznik> #chair adamw, tflink
19:15:00 <zodbot> Current chairs: adamw jreznik tflink
19:15:08 <adamw> pasik: thanks. compare to the rc3 live - https://dl.fedoraproject.org/pub/alt/stage/18-RC3/Live/x86_64/
19:15:14 <jreznik> #topic blocker review
19:15:20 <adamw> 'prerc3' is a misnomer in that filename, btw, it's more prerc4.
19:15:28 <pasik> adamw: I just installed f18-rc3; and it still has the fprintd bug.
19:15:31 <jreznik> adamw, tflink: could anyone of you take care of it?
19:15:31 <adamw> okay.
19:15:37 <adamw> tflink: over to you!
19:15:43 <jreznik> pasik: rc3 still contains it
19:15:53 <pasik> jreznik: yep
19:16:00 <tflink> At the moment, we have:
19:16:03 <tflink> #info 3 Proposed Blockers
19:16:04 <tflink> #info 3 Accepted Blockers
19:16:32 <tflink> of the accepted blockers, 2 are VERIFIED and one is ON_QA
19:16:43 <tflink> starting with the currently proposed blockers
19:16:49 <tflink> #topic (893331) unhelpful error when anaconda runs out of memory during package installation
19:16:50 <adamw> the ON_QA one is not blocking the sign-off, btw
19:16:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=893331
19:16:55 <tflink> #info Proposed Blocker, anaconda, NEW
19:17:00 <adamw> it only needs to be pushed stable before we mirror
19:17:35 <tflink> adamw: yep, figured we'd get to that when we got to the bug but I suppose saying it now is less likely to cause concern
19:17:49 <rbergeron> heartburn level dropping slowly? :)
19:17:56 <Viking-Ice> -1/-1
19:18:04 <adamw> clear -1
19:18:15 <rbergeron> -1
19:18:17 <jreznik> -1/-1
19:18:24 <nirik> minus one.
19:18:27 <sgallagh> -1/-1
19:18:29 <tflink> the issue here, as I understand it is that if anaconda runs out of memory/swap during install, the failure mode is not very obvious
19:18:35 <adamw> this is not really new: whenever you end up in the 'twilight zone' where you have more than anaconda's hardcoded minimum amount of RAM, but your actual install config needs more RAM than you have, this happens, always had
19:18:43 <tflink> -1 blocker
19:18:45 <cmurf> -1/-1
19:18:48 <drago01> -1
19:18:52 <jwb> -1 fwiw
19:18:56 <cmurf> seems related to an unreasonable swap size
19:18:57 <drago01> a helpfull message does not fix installation
19:18:58 <drago01> anyway
19:19:01 <tflink> I count -8 blocker
19:19:07 <adamw> it's very difficult to 'fix' because you're in map vs. territory - the only way to know if the install process is going to need more RAM than is available is, well, to run the install process and see if it fails...
19:19:55 <adamw> yup, seems clear.
19:19:57 <jreznik> we are pretty clear on this one it seems -> let's proceed
19:20:14 <tflink> proposed #agreed 893331 - RejectedBlocker - While this is an unfortunate failure mode, this has been true of previous releases and is very difficult to fix. Since this is not a regression, rejected as a blocker for F18 final.
19:20:14 <pjones> also -1
19:20:20 <tflink> ack/nak/patch?
19:20:32 <jreznik> ack
19:20:32 <adamw> ack
19:20:32 <cmurf> ack
19:20:39 <sgallagh> ack
19:20:48 <jwb> ack
19:20:49 <pjones> ack
19:20:50 <nirik> ack
19:20:52 <Viking-Ice> ack
19:20:56 <drago01> a
19:20:57 <tflink> #agreed 893331 - RejectedBlocker - While this is an unfortunate failure mode, this has been true of previous releases and is very difficult to fix. Since this is not a regression, rejected as a blocker for F18 final.
19:21:19 * tflink is skipping 810040 for the moment - leaving it for last to give more time for testing
19:21:34 <tflink> #topic (873144) pressing Esc kills plymouth screen
19:21:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873144
19:21:34 <tflink> #info Proposed Blocker, plymouth, VERIFIED
19:21:46 <adamw> tflink: i was kinda leaving it up to you to call when we close this one
19:21:51 <tflink> This is VERIFIED and already fixed. it doesn't need to be a blocker
19:21:51 <adamw> if you think it's all good now, we can just close it
19:21:57 <tflink> that works for me
19:22:12 <Viking-Ice> how does it work with 883075
19:22:13 <tflink> putting it in the meeting was just a formality since it is still a proposed blocker
19:22:29 <Viking-Ice> mean affect if any?
19:22:34 <adamw> Viking-Ice: in theory 883075 was kind of a tracker bug for this and one or two others
19:22:58 <tflink> yeah, there were multiple ways that the release blocking issue could have been fixed, not sure why this was proposed as a blocker again
19:22:58 <adamw> i think the thing to do now is just to close them both
19:23:04 <adamw> unless anyone has any objections to that
19:23:14 <drago01> if it is fixed anyway
19:23:16 <drago01> just move on
19:23:30 <jreznik> move on
19:23:38 <sgallagh> Just to confirm, when we say "Fixed" we mean "is present in RC3" right?
19:23:38 <tflink> #info this is VERIFIED and has been fixed, will be closed shortly and thus, doesn't need to be discussed here
19:23:55 <Viking-Ice> yup next bug
19:24:04 <adamw> sgallagh: effectively, yeah. with fedup it's slightly complicated, but that's the executive summary.
19:24:06 <tflink> sgallagh: yes, it is fixed in RC3
19:24:16 <sgallagh> ok, thanks for the clarification
19:24:23 <tflink> #topic (810040) F17/F18 xen/kvm/vmware/hyperv guest with no USB: gnome-shell fails to start if fprintd is present
19:24:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=810040
19:24:28 <tflink> #info Proposed Blocker, fprintd, ASSIGNED
19:24:31 <tflink> now for the fun one ...
19:24:50 <jreznik> not the fun one...
19:24:52 <tflink> my understanding of the issue is that gnome-shell is failing right away on VMs w/o USB
19:25:08 <tflink> the cause is reported to be fprintd
19:25:24 <adamw> it's not really 'VMs w/o USB'
19:25:25 <crobinso> tflink: yeah gdm gives the fail whale, so dropping to tty is the only option
19:25:28 <adamw> it's 'any machine without a USB bus'
19:25:40 <adamw> it's just that that happens to almost always affect certain virt platforms.
19:25:43 * konrad grabs some popcorn
19:25:46 <sgallagh> Out of curiosity, do we know if this is also true of a physical box with the USB hardware disabled in BIOS/EFI?
19:25:47 <pjones> that's just much more likely to be vm's these days
19:26:09 <jreznik> and only some virt. platforms
19:26:10 <adamw> sgallagh: I dunno if anyone's explicitly tested it, but i would expect it would happen, yeah.
19:26:28 <tflink> if we take this as a blocker, we would need to run through a lot of test cases again and the risk of slipping is not small
19:26:33 <sgallagh> adamw: I mostly ask because that could potentially impact appliance devices as well
19:26:52 <Viking-Ice> tflink, fprint/gdm related test cases
19:26:55 <pasik> ok, verified. F18-RC3-live says "Oh no! Something has gone wrong" (the fprintd bug), and adamw's test-build live works OK.
19:27:02 * nirik already voted in bug. Happy to try and convince people if there are folks on the fence about it.
19:27:03 <adamw> sgallagh: stuff like our AMI build generally don't include fprintd (or gdm for that matter)
19:27:08 <jwb> sgallagh, people run gnome-shell on appliance devices _and_ disable USB?
19:27:10 <sgallagh> True
19:27:32 <adamw> pasik: just as a sanity check, aside from this bug, Xen is working OK?
19:27:35 <sgallagh> jwb: True, the combination is... unlikely
19:27:42 <adamw> pasik: if we pretended this bug didn't exist, we could mark the Xen test case as a pass?
19:27:55 <tflink> we are currently at +6/-4 from votes in the bug
19:28:08 <adamw> well, that depends on how you count.
19:28:15 <pasik> adamw: yep, I installed F18-RC3 as 32bit PV domU, 64bit PV domU, and as 64bit HVM - all worked OK. (well, except the fprintd bug).
19:28:23 <jreznik> pasik: thanks
19:28:39 <tflink> I was counting explicitly stated votes in bug comments, did I miss  something?
19:28:46 <jreznik> if anyone wants to add votes to the bug, please do so
19:28:48 <Viking-Ice> for those that want to do quick dirty google search and how this turned out for F17 just search fedora vm fprintd
19:28:49 <adamw> according to the blocker SOP, the groups who get to vote on blockers are QA, releng, and devel. in practice we usually include 'leadership' (so fpl/fpm) too. who you want to count as in those groups and hence how you want to count the votes could get fun, if we make this purely a majority vote thing.
19:29:14 <pasik> the fprintd bug also affects stock xen PV domU installs; if you virt-install F18 PV domU you'll get the fprintd bug.. that's cosmetic, you can of course go to console and install the update..
19:29:33 <cmurf> -1 blocker for a cosmetic bug
19:29:34 <Viking-Ice> you can do deeper forums etc search for all the negativity etc..
19:29:36 <adamw> in meetings we usually just take votes from whoever shows up as a practical matter (and because most votes turn out unanimous or close to it anyway), but we don't really want to just count every vote from any tom, dick or harry who's affected by a bug with the same weight as anyone else's vote...
19:30:12 <sgallagh> Do we have a sense of how invasive the fix in RC4 could potentially be?
19:30:23 <adamw> note that despite my blowup in the bug, i'm pretty close to a +1 on this, even. it _is_ a pretty crappy bug. i was just really pissed off by the late nomination.
19:30:28 <jreznik> sgallagh: it could affect gdm
19:30:41 <jreznik> at least
19:30:41 <sgallagh> jreznik: That's still a little vague.
19:30:48 <adamw> it _shouldn't_ be a major deal as the update was to fprintd not gdm, but tflink calls that 'the s word'
19:30:52 <pjones> adamw: at this point, could we pull in a fix without further slippage?
19:31:09 <sgallagh> Is that "GDM's fingerprint stack might not work" vs. "potentially no one can log in"?
19:31:11 <jreznik> pjones: we would have to do some more smoke testing
19:31:22 <adamw> pjones: if we get quite fudgey, yeah. rc4 is being built now (it was supposed to be done for this meeting). we could give it as much of a smoke test as we can today and aside from that consider rc2/rc3 tests to apply to it.
19:31:50 <adamw> i'd be happy applying most of the install test results to rc4 (same as we did for rc2 vs. rc3) as it's pretty implausible that this change could somehow break, you know, LVM support or whatever
19:31:58 <Viking-Ice> sgallagh, that can be fixed via update while what we ship on the live and dvd without users having to deal with the failwhale first
19:32:04 <pjones> adamw: right.
19:32:07 <adamw> it would be good to explicitly re-do the desktop login test at least for the change (i've done that on my live image and it appears to work)
19:32:21 <rbergeron> but if it does wind up being invasive for some idiotic reason?
19:32:27 <pasik> sgallagh: at least I can log in from gdm to adamw's fprintd-fixed testbuild live-image :)
19:32:42 <pjones> my gut says: people aren't installing virts from disconnected machines with the repo on a CD.  This is something we can fix in the repo if it's going to cause a slip.
19:32:44 <adamw> rbergeron: if you want me to get fudgey, there is the hacky option of saying this:
19:32:56 <rbergeron> i know where you're going :)
19:33:05 <sgallagh> Viking-Ice: I'm trying to figure out if we can include this fix without slipping another week is all. I'm in favor of doing it if someone can convince me the risk is small enough.
19:33:15 <sgallagh> So far I'm not quite convinced of that :(
19:33:19 <adamw> "F18 is GO. either RC3, or RC4. If RC4 proves to pass basic testing, we're shipping that. If it somehow blew up in compose, we're shipping RC3."
19:33:25 <adamw> it's a horrible fudge. hey, this is fedora.
19:33:31 <rbergeron> needinfo via testing of an rc4 to see how risky it is and if a potential fix would actually fix it? :)
19:33:35 <jreznik> one possibility is to pre-accept rc4 today based on smoke testing and try another go/no-go tmrw - we would be still able to make tuesday release...
19:33:53 <adamw> rbergeron: pasik has confirmed the fix with my unofficial live image test
19:34:03 * dgilmore says we ship RC4 if it proves to blow up we ship RC3
19:34:07 <dgilmore> either way we ship
19:34:12 <rbergeron> adamw: yeah
19:34:22 <jreznik> dgilmore: yep, even I'm still more inclined to rc3
19:34:37 <adamw> i consider myself just about qualified to build a live image properly, so i'd say we're pretty confident the fix actually _works_, for the xen case.
19:34:40 <pjones> yeah, it seems like an awfully uncommon bug to hit, tbh.
19:34:42 <Martix> dgilmore: adamw agree
19:34:43 * spot is fine with shipping RC4 (and falling back to RC3 if desktop smoke testing fails somehow)
19:35:00 <Viking-Ice> same here with spot
19:35:05 <adamw> pjones: well, running live images in VM isn't a particularly weird thing to do.
19:35:06 <Martix> someone #propose this condition
19:35:09 <tflink> I could live with that, too
19:35:14 <adamw> well
19:35:20 <adamw> remember we're still discussing the status of this bug
19:35:29 <adamw> if that's teh decision people favour, i guess this technically makes this bug NTH
19:35:30 * tflink is writing proposed for this bug
19:35:35 <Viking-Ice> can we ping halfline for the feedback?
19:35:37 <pjones> adamw: yeah, true.
19:35:39 <konrad> Just point me to the RC4 URL  and I can run the tests.
19:35:41 <adamw> which would mean we're violating the compose request SOP, but oh well.
19:35:53 <Viking-Ice> on how potentially fatal this is
19:35:54 <tflink> actually, I'd say blocker to force the respin. drop as a blocker if it causes problems
19:35:59 <drago01> do we have rc4 already?
19:36:00 <adamw> konrad: RC4 is still composing, but to confirm pasik's test of the fix, you can use http://adamwill.fedorapeople.org/20130109-prerc3-x86_64.iso .
19:36:01 <Martix> -1 blocker/+1 NTH as I wrote in comment
19:36:04 <rbergeron> we should still go through everything else before sticking the shipit stamp on just to be ... anal, i guess
19:36:18 <konrad> adamw, Yeah, the download of that is slloooowwww
19:36:18 <adamw> tflink: it all comes down to which part of the process we want to say we're fudging :)
19:36:21 <adamw> konrad: ah
19:36:55 * nirik is with Martix, but if people really want to try shipping rc4, I won't hold it against them. much. ;)
19:36:55 <drago01> +1 blocker not being able to run live images in vm is not something we can fix post release ... and we have a fixed package anyway
19:37:02 * jreznik is pinging halfline
19:37:08 <pasik> are any of the people who reported the fprintd hyper-v problem here for testing?
19:37:10 * halfline has been watching the chat go by
19:37:25 <adamw> to go back to the impact for a minute, as I read it, this is unlikely to affect most KVM and VBox cases, apparently likely to affect Xen and hyperv cases. vmware i think depends on which vmware product we're talking about.
19:37:44 <dgilmore> im +1 to this being NTH
19:37:45 <adamw> xen is the most important case, as it's the one we have a criterion for.
19:37:47 <tflink> adamw: true, I'm not seeing any obvious criterion violations so blocker would be a fudge
19:37:53 <Martix> and only offline VM
19:37:57 <halfline> i pretty much agree with most people here
19:38:05 <sgallagh> adamw: Just as a data point, does RHEL 6's KVM support USB these days? I'm pretty sure it didn't as recently as 6.1
19:38:11 <adamw> tflink: oh, it's actually a pretty clear blocker by the criteria, see https://bugzilla.redhat.com/show_bug.cgi?id=810040#c81
19:38:11 <halfline> the experience for virt guests is especially important at GA time
19:38:12 <Martix> halfline: which group'?
19:38:13 <jreznik> halfline: that means?
19:38:16 <halfline> because that's what reviewers use
19:38:21 <adamw> sgallagh: really? heck if i know, I never run rhel.
19:38:27 <drago01> adamw: (I still don't think that a sepcific vm should be in the criteria ... either the vm has enough users to make us care or not)
19:38:30 <Martix> halfline: blocker or NTH-only?
19:38:37 <adamw> halfline: i think most of 'em use VBox, though.
19:38:44 <nirik> sgallagh: yes, it does I am pretty sure.
19:38:47 * nirik can check
19:38:48 <tflink> adamw: no, it's not. this bug doesn't violate that criterion completely
19:38:53 <crobinso> sgallagh: just about no qemu/kvm guest that libvirt has ever created will hit this bug unless the user manually fiddles with things
19:38:57 <halfline> adamw: not sure, i'd expect a lot to use parallels honestly
19:38:57 <pjones> halfline: won't reviewers mostly configure with usb of some kind?
19:39:03 <adamw> tflink: well, yeah, you could argue that 'add a usb bus or remove fprintd' are workarounds.
19:39:07 <tflink> the final xen criterion is for cloud providors
19:39:13 <adamw> so i guess by the criteria we can go either way.
19:39:24 <cmurf> there is a stated work around for the bug, so it doesn't seem to be a blocker on the merit
19:39:26 <pjones> yeah, I'm honestly not sure this bug meets the criteria
19:39:41 <adamw> still, let's just pick one fudge and go with it, i don't care which
19:39:42 <jreznik> halfline: how intrusive is the latest change?
19:39:43 <tflink> are there xen cloud providors that have a graphical interface?
19:39:46 <crobinso> sgallagh: you are thinking of host USB device assignment, this is about emulating a usb bus. libvirt always tells qemu to emulate usb
19:39:51 <tflink> I don't know of any
19:39:51 <nirik> adamw: the release boots fine.
19:39:59 <halfline> i wouldn't block the release for this, but i wouldn't block rc4 for being the release either
19:40:02 <nirik> adamw: you just can't login with gdm. ;)
19:40:02 <sgallagh> crobinso: Thank you for clarifying that point. I follow now.
19:40:03 <adamw> if the bottom line is as everyone seemed to agree 'ship rc4 if it works, ship rc3 if it doesn't', we can do the process fudging either way.
19:40:09 <konrad> pasik, any ideas on the cloud providers?
19:40:10 <halfline> so i think it's NTH++ or blocker--
19:40:14 <konrad> tflink, I know Oracle does.
19:40:16 <dgilmore> adamw: we can accept as NTH
19:40:18 <pjones> halfline: yeah.
19:40:33 <halfline> jreznik: patch is pretty small, it just moves some initialization code earlier to make dbus happy
19:40:41 <adamw> konrad: that phrase is basically code for 'ec2'.
19:40:46 <tflink> konrad: with xen as the hypervisor?
19:40:51 <konrad> tflink, Aye
19:40:53 <adamw> mattdm has tested the EC2 AMI, it works fine.
19:40:54 <tflink> did not know that
19:40:55 <halfline> unfortunately, when dbus is unhappy it has bad consequences
19:41:00 <halfline> but the fix, fixes those consequences
19:41:03 <adamw> if EC2 AMI was busted, we'd make it a blocker under that wording in the criteria.
19:41:04 <drago01> adamw: well "t must be possible to run the default web browser and a terminal application from all release-blocking desktop environments." if you can't login ...
19:41:06 <halfline> so it's not likely to make things worse
19:41:08 <halfline> only better
19:41:10 <halfline> and it's tested
19:41:15 <drago01> it violates a lot of desktop criteria
19:41:37 <tflink> for xen, yes but xen is not a release-blocking hypervisor with the excpetion of cloud images
19:41:39 <adamw> tflink: just run something up the flagpole and see what happens
19:41:42 <konrad> adamw, Right, but that is probbly b/c the fprintd RPM isn't in the AMI image. If the iso was used instead...
19:41:43 <nirik> FWIW, rhel6 libvirt/kvm does have usb ( sgallagh )
19:41:55 <pjones> drago01: not given a) there's a simple workaround, and b) typical desktop machines have usb
19:41:57 <adamw> tflink: no, the criterion says "must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen"
19:42:01 <adamw> tflink: note the "and*
19:42:07 <jreznik> so if we want to test this one - what would be the way to go - the whole gnome desktop test matrice + anything else specific?
19:42:10 <sgallagh> nirik: Yes, thank you. crobinso corrected my misunderstanding above (I was confusing USB passthrough with USB support)
19:42:17 <adamw> in other words, "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0" is a requirement on its own.
19:42:47 <adamw> jreznik: the absolute minimum is just the desktop_login test case
19:42:50 <tflink> huh, that was a mistake on my part, then. I don't think that was the intention but that doesn't matter - it says what it says
19:42:51 <jreznik> it's more about do we consider xen as the must for desktop test cases or bare metal/kvm
19:42:57 <pjones> adamw: but that's not the same as "must work no matter how you configure your virt host"
19:43:08 <pasik> so F18-RC3 does not boot successfully as Xen PV domU; you get the "Oh no! Something has gone wrong" fprintd crash instead of gdm login prompt.
19:43:09 <adamw> jreznik: ideally it'd be nice to verify the whole desktop matrix, and then just the automated checks for stuff like checksums, ISO size, repo sanity
19:43:12 <adamw> robatino will run those anyway
19:43:16 <rbergeron> tflink: rackspace cloud? for xen cloud provider with graphical interface? maybe?
19:43:19 * rbergeron isnt' sure
19:43:32 <adamw> pjones: yes, there's wiggle room for sure. i'm just saying tflink's contention the criterion _only_ applies to cloud providers is not correct.
19:43:33 <pjones> pasik: ... if you've configured with no usb emulation
19:43:46 <pasik> pjones: PV doesn't have USB
19:43:57 <pasik> pjones: as a default
19:43:58 <pjones> yeah, fair.
19:44:02 <tflink> proposed #agreed 810040 - AcceptedBlocker - Violates the following F18 final release criterion for VMs without an emulated USB bus and gnome-shell isntalled: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0"
19:44:21 <crobinso> pasik: can xen PV boot off cdrom these days?
19:44:24 <drago01> +1
19:44:31 <tflink> unless we want to add conditionals on RC4 not working
19:44:39 <pjones> tflink: I see at least 4 of us saying blocker--/nth++
19:44:42 <pasik> crobinso: this also affects virt-install installs
19:44:45 <jreznik> tflink: propsal or do we want to vote for blocker status first?
19:44:53 <adamw> ack (i would also ack an nth proposal)
19:44:54 <tflink> jreznik: I already did a proposal
19:44:56 <sgallagh> tflink: I'm inclined to agree, but what are we talking about for testing time? Another slip?
19:45:02 <adamw> either way on the understanding we fudge to rc3 if rc4 has problems.
19:45:12 <crobinso> pasik: right, just curious. so no cdrom boot?
19:45:30 <tflink> my thought is to accept as blocker for today and fudge tomorrow to reject if RC4 causes problems
19:45:31 <Viking-Ice> tflink, I think you should add the conditionals
19:45:31 <adamw> sgallagh: no, this is all just about the bureaucracy, as i understand it we're all agreed that we're shipping this week, if rc4 has problems or isn't tested to our satisfaction, we ship rc3.
19:45:33 <sgallagh> adamw: So are we agreed upon shipping something on Tuesday no matter what?
19:45:33 <tflink> or we could do NTH
19:45:41 <jreznik> sgallagh: we still have some buffer - tmrw night is the latest time to distribute to mirrors
19:45:42 <adamw> sgallagh: as I'm reading it, yes
19:45:50 <jreznik> sgallagh: yep
19:45:52 <adamw> we can make that clear later in the meeting
19:46:25 <jreznik> except something else really critical will come up
19:46:27 <sgallagh> Then at that point: Damn the torpedoes. Full speed ahead.
19:46:29 <tflink> pjones: true, but I don't see clear consensus either - technically, we can't respin without a blocker
19:46:33 <pasik> crobinso: I haven't tried cdrom boot with PV.. but I just installed F18-rc3 PV domU using virt-install http install, and the end result is you get F18 PV domU with the fprintd issue in the graphical console.
19:46:41 * nirik is happy to bow to others on acking this. I'd personally prefer we go with rc3, but thats fine.
19:46:53 <pjones> tflink: and it's unclear to me that we need to.  RC3 doesn't obviously fail to meet the criteria.
19:47:05 <sgallagh> halfline: Do you have a handy pointer to the patch that fixes this?
19:47:07 <pjones> in fact it's a fairly serious stretch to say that it does.
19:47:10 <pasik> crobinso: that can be fixed by removing the fprintd rpm, so it's basicly only cosmetic for PV domUs.
19:47:21 <halfline-laptop> i think there's a link to it in the bug
19:47:28 <pjones> pasik: ... or by configuring usb
19:47:44 <nirik> or by updating
19:47:46 <pjones> which is to say that there's a simple workaround
19:48:05 <Viking-Ice> if you know what you are doing
19:48:05 <pasik> yep
19:48:09 <pjones> rc3 is well tested.  why are we talking about doing something risky?
19:48:14 <pasik> anyway, adamw's testbuild seems to fix the problem for me
19:48:17 <adamw> because the bug kind of sucks.
19:48:17 <pjones> Viking-Ice: we *always* have a known bugs list.
19:48:24 <pasik> I tested/verified multiple times
19:48:31 <adamw> and the fix isn't really horribly risky.
19:48:39 <Viking-Ice> pjones, reviews and users did not read those for F17
19:48:40 <jreznik> pasik: it's not about fix, it's about all consequences
19:48:54 <pjones> Viking-Ice: reviews are unlikely to test without usb, aren't they?
19:49:12 <pasik> jreznik: I understand that..
19:49:23 <konrad> pjones, Who are the reviewers?
19:49:31 <jreznik> we already copied rc2 to rc3 and now rc4 - really more coverage would be needed
19:49:31 <Viking-Ice> pjones, well that's arguable if you want to determine how widespread of the problem do the google search
19:49:35 <cmurf> is it impossible/bad idea to use LiveCD RC4, and RC3 for DVD?
19:49:35 <pjones> konrad: phoronix :P
19:49:36 <Viking-Ice> for f17
19:49:37 <nirik> FWIW, xfce size is ok on rc4 too.
19:49:43 <konrad> pjones, oh fuck. not them.
19:49:58 <adamw> cmurf: basically impossible
19:50:11 <adamw> cmurf: we have to have a single frozen package set which all images are built from
19:50:19 <tflink> since I've seen only 1 ack on the blocker proposal, I assume that is pretty much not accepted
19:50:21 <cmurf> understood
19:50:23 <konrad> pjones, yeah, well if that is then you might as well do the rc4 as they will bitch. (personal experience but it might be differnet now)
19:50:29 <adamw> we can fudge a tiny bit when we change the base set and a given spin's package set doesn't change, but we can't have different packages in the lives and DVD
19:50:30 <drago01> konrad: well I doubt they use vms
19:50:31 <Viking-Ice> pjones, this was broken last release we have a data point what happened then so this is a question do we want this to happen again or release with a fix since the fix exist
19:50:37 <pjones> konrad: I find it unlikely they'll notice tbh
19:51:00 <rbergeron> tflink: i think others were thinking of a "rc4 or rc3 if rc4 is fail"
19:51:11 <konrad> tflink,+1 on blocker. her
19:51:14 <pjones> Viking-Ice: we can release with a fix in the repos but not on install media.
19:51:22 <drago01> rbergeron: yeah that is ok I guess
19:51:25 <pjones> Viking-Ice: and AFAICS that meets the criteria just fine since there's a simple workaround.
19:51:26 <konrad> tflink, Oh wait, the fallback!, the rc4 fallback rc3.
19:51:26 <cmurf> pjones: yes. this has been the case for something like 8 months and was just proposed as a blocker today.
19:51:38 <konrad> tflink, not sure if that is half-blocker or claw-back-blocker
19:51:48 <adamw> well it seems like people are changing their minds.
19:51:49 <sgallagh> Actually, at this point I'm rethinking my position. I'd rather stick with RC3 and include it in the known bugs list
19:51:54 <pjones> cmurf: that's a pretty solid argument that we shouldn't fix it in a risky way at the last minute.
19:51:54 <pasik> I'd say release rc4 if it works :) otherwise rc3
19:52:01 <pjones> We should really just ship rc3.
19:52:01 <tflink> we're getting into the awesomeness of technicalities
19:52:03 <drago01> can we vote on the "rc4 or rc3 if rc4 is fail" thing?
19:52:06 <adamw> 10 minutes ago everyone was basically in favour of shipping rc4 if basic testing looked good, otherwise rc3, and we were just arguing about how to bureaucratize it.
19:52:14 <adamw> now pjones is making the case for just shipping rc3 whatever.
19:52:27 <Viking-Ice> <sigh>
19:52:27 <pjones> I was making that case 10 minutes ago too :P
19:52:28 * nirik just wants to ship something. ;)
19:52:33 <adamw> pjones: sorry, i must've missed that.
19:52:34 * jreznik is still more with pjones even the fix seems to be ok
19:52:37 <drago01> adamw: just prentend the last 10 min. didn't happen ;)
19:52:46 <Martix> just ship that damn thing :-)
19:52:47 <cmurf> i've been making the rc3 case for 2 hours
19:52:51 <drago01> nirik: we will ship something ... question is when ;)
19:52:53 <adamw> despite being QA and hence supposed to be conservative, i'd quite like to take the fix, but then i'm like that.
19:53:15 <adamw> i am entirely okay with either choice in the end, just so long as we're shipping this damn week.,
19:53:24 <Viking-Ice> pjones, the fix being in repo does not help the cause until after you have installed and hit the fail whale or done a net install
19:53:34 <cmurf> there is a lot of work to do by QA to qualify/test RC4, so if QA is literally happy doing that then I would +1 RC4.
19:53:37 <pjones> Viking-Ice: no, the workarounds solve that.
19:53:47 <sgallagh> If we're shipping "this damn week", then let's stick with what we know works and publicize the workarounds
19:53:50 <dgilmore> adamw: +!
19:53:51 <pjones> cmurf: note that they're not talking about re-doing most of that work.
19:53:51 <dgilmore> +1
19:53:58 <rbergeron> cmurf: indeed
19:54:02 <pjones> cmurf: they're talking about applying the rc3 work to rc4 and plugging their ears.
19:54:03 <adamw> cmurf: i wasn't planning a full re-run of the matrix for rc4, just sanity checks and desktop spin tests.
19:54:14 <nirik> so, if we do: rc4 or rc3 if it fails, when is the go/no-go on rc4?
19:54:22 <nirik> ie, how much retesting time should we allow?
19:54:23 <adamw> tomorrow, i believe.
19:54:28 <tflink> yeah, tomorrow
19:54:30 <Viking-Ice> yup
19:54:30 <adamw> but you're the owners of that :)
19:54:45 <konrad> so who do I poke if it is busted?
19:54:45 <sgallagh> one day is not enough time to retest desktop comfortably in my estimation
19:54:55 <jreznik> sgallagh: it is enough
19:54:55 <pjones> proposal: go on rc3
19:54:56 <adamw> konrad: comment in the bug report.
19:54:59 * konrad nods
19:55:03 <sgallagh> Especially given that the RC4 disk is downloading at approximately one quarter of molasses speed
19:55:04 * nirik is also afraid of "oh, but this other NTH didn't get in rc4" or "this other year old bug is a blocker" syndrome
19:55:06 <adamw> sgallagh: we can knock out the whole desktop matrix in about two hours.
19:55:19 <adamw> we've done the entire final release validation matrix in 12 before, but i'm fucked if i'm doing that again.
19:55:27 <cmurf> is there a deltaiso for RC4?
19:55:28 <tflink> adamw: +1
19:55:45 <pasik> is rc4 already available?
19:55:48 <adamw> cmurf: there will be when it's done.
19:55:51 <jreznik> pasik: yes, it is
19:55:55 <adamw> they get auto-generated.
19:56:02 <pasik> jreznik: then I'll start testing it
19:56:03 <robatino> not really
19:56:10 <jreznik> lives are
19:56:16 <dgilmore> i386 dvd is up
19:56:19 <pjones> nirik: I think that's pretty solidly the reason this is even being considered
19:56:36 <adamw> robatino: i was counting you as a bot. :)
19:56:54 <pasik> eta 4 mins for the rc4 live-image
19:56:55 <jreznik> summary: for now we agreed to ship rc3 or rc4 but we are currently in Go mood
19:57:02 <nirik> pjones: sure, but my point is that if we say 'ok, lets check on rc4 tomorrow' we may well get more of these coming out of the woodwork
19:57:03 <Viking-Ice> I dont think waiting a day and do the desktop matrix test is to much to ask for the upside for this
19:57:03 <cmurf> I understand the risk assessment for RC4 is considered low, but the whole point of the test matrix is that the actual release is tested with that matrix as a barrier to "oh shit" happening. It's like buying insurance. Chances are your premium is going bye bye.
19:57:07 <Viking-Ice> vs the downside
19:57:16 <cmurf> So I say just take RC3 if RC4 isn't getting the whole matrix.
19:57:17 <tflink> proposed #agreed 810040 - RejectedBlocker AcceptedNTH - While a nasty bug, it was judged too much of a corner case to block release of F18 at this point (only a subset of xen VMs would hit this in certain install types). However, a tested fix would be considered for F18 final after freeze.
19:57:19 <pjones> we can't (or won't) do the full test on it, there's a simple work around, and nobody seems to have minded that much for F17.  It's hard to say how calling it a blocker is at all realistic, or meets the criteria.
19:57:27 <tflink> note that rejected blocker doesn't mean "no rc4"
19:57:31 <jreznik> if we could do the rc4 testing in that two hours, would it be ok for folks to wait (and help) and then agreen on rc3 or rc4?
19:57:38 <konrad> tflink, You forgot Vmware and hypoerv in there
19:57:39 <Martix> ack
19:57:40 <tflink> just moving the process fudge out of the blocker process
19:57:50 <adamw> cmurf: it's pretty ridiculous to re-test hardware RAID installation for an image which is identical to the previous one except for a fingerprint reader library fix.
19:58:00 <tflink> konrad: vmware and hyperv aren't potentially release blocking hypervisors - i left them out intentionally
19:58:02 <konrad> tflink, oh wait, you are framing it mind of the release criteria, sorry
19:58:03 <adamw> ack
19:58:10 <rbergeron> ack
19:58:13 <jreznik> ack
19:58:17 <nirik> ack
19:58:23 <Viking-Ice> ack
19:58:26 <konrad> nack
19:58:30 <cmurf> ack
19:58:32 <tflink> konrad: patch?
19:58:38 <nirik> so, if we do ack that that means we ship rc3?
19:58:41 <adamw> nirik: no
19:58:47 <adamw> "<tflink> just moving the process fudge out of the blocker process"
19:58:48 <pjones> nirik: it means we /can/, I think.
19:59:00 <jreznik> yep, we can
19:59:07 <tflink> yes, I'm leaving the "which release to ship" for another discussion
19:59:10 <drago01> does it mean "try rc4 if it is broken snip rc3" ?
19:59:13 <rbergeron> we can,if rc4 proves to be riddled with the bads
19:59:15 <konrad> adamw, oh wait, this is the rc4 claw-back.
19:59:16 <jreznik> and we would be clear on rc3 at least
19:59:26 <cmurf> it means RC3 is it, unless RC4 meets QA's blessing
19:59:27 <pjones> <jlk> even if they are created with /exactly/ the same content, there is shit that can go wrong in the compose process.
19:59:30 <adamw> drago01: it means 'argue about that later in the meeting'
19:59:33 <pjones> (was re: why we should ship rc3.)
19:59:34 <tflink> drago01: it can, but that is somewhat orthoganal to the question of which release to ship
19:59:36 <konrad> cmurf, If htat is the case, then ack
19:59:41 <adamw> pjones: i know, hence the sanity check.
19:59:55 <tflink> this would allow us to ship RC4 but makes no decision on which to ship
19:59:55 <adamw> pjones: but if we run it through a few test installs and they work out fine...
19:59:56 <nirik> well, repinning for just a NTH doesn't make sense to me. ;) but ok.
20:00:03 <sgallagh> Perhaps we should take this in steps. Could we vote on who feels that the 2-hour desktop-only matrix is sufficient coverage for RC4?
20:00:04 <pjones> adamw: point being, your point about not doing e.g. raid testing doesn't really make sense.
20:00:07 <tflink> nirik: we need to fudge somewhere
20:00:13 <tflink> if we're going to ship RC4
20:00:16 <pjones> adamw: other things may be wrong.  we don't know.
20:00:39 <pjones> it's a large risk for a very small gain that somehow has been arbitrarily elevated to be the one thing left.
20:00:46 <tflink> #agreed 810040 - RejectedBlocker AcceptedNTH - While a nasty bug, it was judged too much of a corner case to block release of F18 at this point (only a subset of xen VMs would hit this in certain install types). However, a tested fix would be considered for F18 final after freeze.
20:00:51 <adamw> pjones: that applies just as much to rc3, then.
20:00:57 <Viking-Ice> yup
20:01:04 <nirik> tflink: we don't _need_ to fudge. ;)
20:01:05 <tflink> OK, that would be all of the proposed blockers
20:01:06 <jreznik> pjones: and even the rc4 compose was done on the second try this time...
20:01:10 <pjones> well, less so, in that more people have /already/ tested rc3
20:01:24 <adamw> nirik: if we accept this as a blocker then rc4 turns out busted, we'd be fudging again.
20:01:32 <tflink> nirik: which is why I added the comment below that. "if we want to ship rc4"
20:01:37 <pjones> we've already not accepted it as a blocker.
20:01:40 <adamw> pjones: that testing is literally just a few people smoke checking it: it's exactly what I was saying we'd do for rc4.
20:01:56 <nirik> adamw: if we wanted to not slip. ;)
20:01:58 <nirik> anyhow.
20:02:08 <nirik> where do we go from here?
20:02:13 <tflink> can we put the RC4/RC3 discussion on hold for a minute while we wrap up the blocker discussion?
20:02:15 <adamw> pjones: sorry, read that as 'if we had accepted this" - the point being that the whole 'ship rc3 or rc4 depending on results' plan necessarily involves some kind of fudge somewhere.
20:02:22 <notting> nirik: to the bar?
20:02:23 <sgallagh> adamw: A mouse could starve on the difference, but we're talking about a respin that changed code vs. a respin that changed content.
20:02:29 <jreznik> could we prolong this meeting for now and let's try the testing?
20:02:29 <nirik> notting: +1
20:02:31 <pjones> adamw: but one is less resky.
20:02:33 <pjones> risky
20:02:45 <nirik> tflink: any other blockers to address?
20:02:48 <adamw> sgallagh: but the argument is 'it could be broken by the compose process, so you have to test everything' - which applies equally to both kinds of respin.
20:02:53 <adamw> we've already tested the code change itself.
20:03:14 <jwb> jreznik, do you mean defer the meeting?
20:03:15 <tflink> nirik: nope - the only other non-VERIFIED but is not on the media and thus doesn't affect go/no-go
20:03:16 <adamw> but pjones is arguing we have to re-test everything with every respin.
20:03:27 <Viking-Ice> yup
20:03:42 <adamw> anyway, +1 to tflink's idea
20:03:44 <tflink> I suppose that it would be best to go through the motions on that one
20:03:48 <adamw> let's knock out everything else
20:03:52 <jreznik> jwb: no, the meeting could be still on and then make the call
20:04:01 <tflink> OK, that is all of the proposed blockers
20:04:05 <pjones> No, I'm arguing that we /should/, but that the testing we've already got of rc3 does exist, and there's no compelling reason according to our criteria to have done another spin at all.
20:04:05 <jwb> that sounds horrible.
20:04:10 <tflink> there is one accepted blocker that is not yet VERIFIED
20:04:14 <tflink> #topic (893286) Final build of F18 generic-release / generic-release-notes is not in stable
20:04:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=893286
20:04:19 <tflink> #info Accepted Blocker, generic-release, ON_QA
20:04:24 <adamw> jwb: that's how we fudged beta :P
20:04:30 <pasik> I confirm F18-RC4 live-image has the fprintd bug fixed, and it seems work OK with initial quick testing.
20:04:33 <adamw> we ran the meeting for like 12 hours. that's why it's in meeting-2.
20:04:41 <adamw> pasik: thanks.
20:04:41 <jwb> adamw, by indefinitely extending a _meeting_??
20:04:51 <adamw> jwb: yeah, we just left the meeting running while we did the testing.
20:04:51 <jwb> how on earth is that fscking sane
20:04:54 <tflink> #info this bug does not affect the F18 media and thus does not have to be VERIFIED to ship media
20:05:00 <rbergeron> jwb: and multiple times in f17 or f16 iirc.
20:05:02 <adamw> THIS ISN'T SANE. THIS IS FEDORAAAAAAAAAAAAAAA
20:05:04 <jreznik> jwb: not indefinitely but it's really the reason for -meeting-2
20:05:20 <tflink> seriously - can we finish up the blocker discussion before deciding what we're going to ship?
20:05:27 <tflink> or going to attempt to ship?
20:05:30 <jreznik> tflink: yep, sorry :)
20:05:31 <adamw> sorry, tflink
20:05:33 <jreznik> move on
20:05:43 <adamw> generic-release is not on the media, only has to be in the repos prior to mirroring
20:05:45 <cmurf> ok so the patch works, but how does fprintd touch dbus? Is there a chance some significant minority case exists in the wild where a USB device attached now causes a problem where a problem doesn't occur with RC3?
20:05:56 <pjones> tflink: sure.  what's next in the blocker discussion?
20:06:07 <tflink> pjones: already changed topic
20:06:24 <Viking-Ice> pjones, generic-release what we are trying to discuss here
20:06:36 <pjones> well, go ahead.
20:06:41 <tflink> #info the packages will be done before release and thus, this doesn't need to be closed prior to deciding on go/no-go
20:06:42 <jreznik> I think we are clear on generic-release as it's not on media
20:06:56 <pjones> jreznik: yeah, I thought we were too.
20:06:56 <adamw> it would help if someone who knows about generic-release could decide what actually needs doing, though.
20:07:07 <adamw> it's not clear if we just need to push 18-1 stable or we need to build an 18-2 with updated release notes content.
20:07:33 <adamw> i don't know why fedora-release-notes is its own srpm but generic-release-notes gets built from generic-release , that seems screwed up. i thought they were meant to be parallel.
20:08:13 <dgilmore> adamw: no idea generic-release* came way after fedora-release*
20:08:15 <jreznik> do we want to "fix it" before ga?
20:08:42 <dgilmore> adamw: the nice thing is that fix just needs to be done in the Everything repo
20:09:06 <dgilmore> that has slightly more time
20:09:21 <adamw> jreznik: it *has* to be fixed for GA (by mirroring time), that's why it's a blocker. but it doesn't have to be on the gold *media*, because generic-release is not on the media.
20:09:22 <jreznik> dgilmore: what does more time mean?
20:09:31 <jreznik> adamw: I understand
20:09:40 <dgilmore> jreznik: couple of days
20:09:44 <jreznik> the question is do we want to fix that srpm thing?
20:09:45 <adamw> jreznik: if you could find someone to decide whether we need a new package or not that'd be aces.
20:09:51 <adamw> otherwise we'll just push 18-1 and hope for the best.
20:09:54 <dgilmore> jreznik: before i switch branched off
20:10:01 <jreznik> adamw: I'll try
20:10:03 <notting> adamw: there's no content in generic-release-notes
20:10:03 <adamw> jreznik: we don't want to change the srpm situation before GA, it was just a side note.
20:10:12 <adamw> notting: ah, that was the info i needed, i think.
20:10:29 <tflink> #info it's still unclear whether a new generic-release package is needed before GA
20:10:34 <adamw> should've checked repoquery -l
20:10:39 <tflink> #undo
20:10:39 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xadb9f50>
20:10:41 <jreznik> tflink: it's clear
20:10:47 <jreznik> it has to be
20:10:49 <notting> adamw: not sure whether the *need* for content-free generic-release-notes is still there, but that's not a f18 blocker issue
20:10:57 <jreznik> we are discussing "how"
20:11:01 <adamw> notting: yeah, we should check that
20:11:20 <adamw> anyways, seems clear enough now
20:11:29 <adamw> we just need to upkarma generic-release 18-1 and push it stable. simple.
20:11:33 <adamw> can you info that tflink?
20:11:55 * jreznik was about to info that but let tflink to do it
20:12:09 <tflink> #info this just needs generic-release-18-1 upkarmad so that it can be pushed to stable before GA
20:13:05 <jreznik> let's move on
20:13:20 <tflink> assuming my #infos summed it up well enough, that is all of the remaining proposed blockers and accepted blockers not already VERIFIED or CLOSED
20:13:27 <tflink> yep, done with the blocker discussion
20:13:39 <rbergeron> :)
20:13:46 <adamw> okay guys, i am screwing off for a few hours. my personal vote is we are go today. i am OK either with just shipping rc3 or keeping an option on rc4.
20:13:57 * rbergeron salutes adamw
20:13:58 <adamw> if we keep the option on rc4 I'll do as much validation as possible tonight.
20:14:06 <adamw> if not, then fine.
20:14:13 <adamw> tflink and viking can rep qa officially
20:14:43 <jreznik> adamw: well if you're leaving, could we just do the call right now?
20:15:00 <adamw> eh, i don't mind missing it.
20:15:11 <adamw> one last note, rc4 gets us a good-sized xfce live
20:15:14 <adamw> rc3 xfce came out oversized
20:16:10 <rbergeron> well, that's a side dish of good for a change :)
20:16:11 <Viking-Ice> my take is allow us QA do the desktop validation matrix and if it turns up nothing ship rc4 else ship rc3
20:16:23 <jreznik> #topic go/no-go
20:16:34 <sgallagh> adamw: How did this change affect the size of the XFCE spin?
20:16:44 <adamw> compose weirdness, it's known, ask nirik/dgilmore
20:16:56 <jreznik> dgilmore: could you provide more input?
20:17:09 * jreznik is scared to hear compose weirdness
20:17:17 <jreznik> in relation to rc4
20:17:35 <jwb> we magically get more space because of compose weirdness, and we aren't concerned the same magic invalidates a test matrix
20:17:36 <dgilmore> jreznik: there is no input to provide
20:17:38 <jwb> ?
20:17:38 <nirik> I'd prefer to ship rc3, but if folks really want rc4, I would be ok with doing that provided testing is good. I want a definite cutoff on that tho.
20:17:48 * pjones also prefers rc3
20:18:01 <pjones> I wouldn't consider the xfce change "good" at this point, since there's no clear reason for it to have happened.
20:18:04 * nirik doesn't know the weirdness, but notting looked into it.
20:18:09 <pjones> in fact that makes me terrified of rc4
20:18:15 <dgilmore> jreznik: its an issue with sparse
20:18:16 <pjones> though I guess that applies both ways.
20:18:24 * jreznik prefers rc3 too
20:18:29 <notting> jreznik: live images size is due to disk usage of sparse filesystem image. this can include blocks touched on the filesystem but deleted during the compose process., and be affected by disk locality, etc, so size can be slightly non-deterministic
20:18:45 <jreznik> uf
20:19:12 <notting> jreznik: fix may be to use fstrim on the filesystem rather than the current copying tricks in live*-creator, but Not Making That Change Now
20:19:14 <pjones> Oh, I see.
20:19:35 <jreznik> does this info provided changes some minds?
20:19:38 <pasik> RC4 worked OK in my testing so far, and it fixed the fprintd bug. that's all I have to say :)
20:19:55 <pasik> doing more RC4 tests now
20:20:40 <tflink> personally, I'm more comfortable with rc3 than rc4 but I won't fight an option to test rc4 as long as we include a hard deadline for it
20:20:48 * jreznik sees more people preferring rc3 now
20:20:57 * pjones still prefers rc3
20:21:00 <Viking-Ice> tflink, tomorrow
20:21:20 <cmurf> does go/no go require a decision on rc3 vs rc4, or can it be "RC3 is a go, RC4 is a go contingent QA meets their stated X testing requirements by Y time"
20:21:23 <sgallagh> I'm slightly in favor of rc3, although not having a properly-sized XFCE spin bugs me a bit.
20:21:27 <notting> pjones: at least, that's what it was when i looked into a random size jump during the TC cycle - i'd assume it's the same for RC changes in xfce size
20:21:34 * nb_ prefers sticking with rc3
20:21:46 <pjones> notting: it's at least a reasonable first guess, yeah.
20:21:49 <sgallagh> cmurf: Well, we don't want to make QA put in the time if we don't want RC4
20:22:18 <cmurf> sgallagh: that has been my argument with QA yet they seem eager to test and therefore ship rc4
20:22:30 <jreznik> what if we delay final decision on something really critical arrises from rc4 testing?
20:22:42 <Viking-Ice> cmurf, yes because this fixes real problem for people
20:22:43 <tflink> cmurf: we do?
20:23:08 <tflink> I count viking as being clearly +1, adam as being slightly +1 on trying and me as being slightly -1
20:23:19 <tflink> unless I'm missing people
20:23:35 <tflink> not sure how that adds up to QA being eager to do it
20:24:09 * dgilmore really doesnt care if we ship RC3 or RC4 i just want to ship
20:24:27 <tflink> yeah, either way, I don't want to slip another week
20:24:28 <Viking-Ice> I think it's pretty clear we ship
20:24:32 * rbergeron is slightly +1 as well but can be ... well, beaten into submission, swayed, etc
20:24:44 <cmurf> tflink: ok well every time the ship starts to lean toward rc3, i start reading contrary to get the ship to lean to rc4
20:24:45 <nirik> proposal: QA to test rc4. reconvene tomorrow same time, same channel.
20:24:47 <jreznik> proposal 1) RC3 is Go, ship RC3
20:24:51 <jreznik> proposal 2) RC3 is Go, but let's test RC4 and decide tomorrow based on the outcome of supplemental testing
20:25:06 <pjones> jreznik: +1 to #1
20:25:11 <jreznik> nirik: well, you were faster, which vote do we want to go with?
20:25:13 <Viking-Ice> +1 #2
20:25:14 <dgilmore> jreznik: i need to stage Final in the morning
20:25:16 <nirik> jreznik: use yours.
20:25:27 <dgilmore> well i guess friday monring
20:25:30 <dgilmore> morning
20:25:32 <jreznik> ok, so let's vote on my proposal
20:25:47 <jreznik> dgilmore: yep, we have spare day (I'm not sure about my availability tmrw)
20:25:50 <sgallagh> +1 to #1
20:25:52 <tflink> dgilmore: so if we decide to ship RC4, deciding tomorrow is ok?
20:26:11 <nb_> +1 jreznik #1
20:26:22 <dgilmore> tflink: i need to stage Friday AM us time
20:26:22 <jreznik> tflink: as always, we just moved the meeting to Wed because most of the people in Brno would not be available tmrw afternoon
20:26:33 <rbergeron> jreznik: i can run the go/no-go if needed, i've done it once or twice
20:26:35 <dgilmore> tflink: so yes deciding tomorrow is ok
20:26:40 <cmurf> jreznik: +1 to proposal #1
20:27:13 <jreznik> rbergeron: it's more how much testing we will get tmrw...
20:27:14 <dgilmore> +1 #2
20:27:15 * nirik is torn. Want Xfce size to be nice.
20:27:21 <nirik> +1 to #2 I guess.
20:27:24 <Viking-Ice> +1 #2
20:27:28 <tflink> +1 #2
20:27:33 <nirik> Viking-Ice: you already voted. ;)
20:27:34 <jreznik> +1 #1
20:27:56 <pasik> +1 #2
20:28:04 <sgallagh> Vote early, vote often?
20:28:20 <rbergeron> jreznik: ahhhh
20:28:23 <tflink> but I don't think that popular vote counts, here
20:28:41 <tflink> overall, it looks like QA is slightly +1 for #2
20:28:44 <jreznik> so if I count it correctly it's 5:5
20:28:56 <sgallagh> of course it is :-P
20:28:59 * rbergeron is +1 to #2
20:28:59 <Acidflash|> =)
20:29:05 <cmurf> OK so it's tied here, and QA gets to break the tie since they do the work :-)
20:29:05 * spot is +1 to #2
20:29:13 <jreznik> ok, so with rbergeron and spot, we are #2
20:29:18 <tflink> jreznik: I don't think its 5:5
20:29:28 <jreznik> tflink: it was
20:29:37 <tflink> I thought that go/no-go was based on votes from QA, PM, releng, devel and FPL
20:29:42 <drago01> +1 #2
20:29:43 <tflink> oh and QA
20:29:51 <tflink> not whoever shows up for the meeting, but either way
20:30:15 <drago01> tflink: aren't the people in the meating in one of those groups?
20:30:24 <jreznik> well how do you want to count whose devel, whose qs?
20:30:26 <jreznik> qa?
20:30:33 <tflink> drago01: yes, but that means 1x +/-1 from each groups
20:30:36 <jreznik> drago01: I'd say so
20:30:39 <tflink> jreznik: slightly +1 overall
20:30:59 <tflink> +1 #2, I mean
20:31:01 <jreznik> tflink: if you want to count it in different way, I'm ok with that
20:31:26 <Viking-Ice> tflink, QA, releng and FPL are +1 to #2 devel PM are +1 to #1
20:31:37 <jreznik> so again the question - if another blocker arises tomorrow, what then?
20:31:47 <nirik> we address it in go/no-go
20:31:54 <nirik> or before if we can in bug
20:31:55 <Viking-Ice> +3 to #2 vs 2 + #1
20:31:56 <jreznik> we are againg going to slippery waters
20:31:57 <dgilmore> jreznik: thats a theoretical future.
20:32:06 <dgilmore> jreznik: we deal in now
20:32:07 <tflink> I am adamantly -1 to slip
20:32:13 <tflink> I think that QA is -1 slip overall
20:32:13 <cmurf> see that's the problem with #2 is that it opens the door to more blockers, and that opens the door to an rc5
20:32:16 <dgilmore> im -1 to slip
20:32:17 <nb_> Well I thought we said rc3 was go if rc4 was not
20:32:27 <nirik> cmurf: yep.
20:32:31 <dgilmore> nb_: yes
20:32:31 <Viking-Ice> tflink, yup
20:32:36 <nb_> So doesn't that mean no more blockers? I thought go was final?
20:32:37 <rbergeron> nb_: it's a "what if we find a bug that is horrible in both"
20:32:38 <sgallagh> Let's not vote to forbid a slip, lest we taunt the devil.
20:32:38 <cmurf> so if testing rc4 is OK, then also there needs to be a door closed on more blockers
20:32:52 <rbergeron> sgallagh: yes please.
20:33:02 <nb_> True
20:33:03 <nirik> right, are we done today then?
20:33:11 <jreznik> no
20:33:22 <dgilmore> jreznik: there is always the possibily that we say go this is gold and someoen says wait i have the blocker
20:33:33 <jreznik> dgilmore: ok
20:33:39 <jreznik> you're right
20:33:56 <dgilmore> jreznik: with what we have now if for some reason RC4 is bad we ship RC3
20:33:57 <nirik> we shouldn't discuss what-ifs or we will be here all day. ;)
20:34:04 <dgilmore> nb_: exactly
20:34:14 <dgilmore> we have a plan lets implement it
20:34:18 <dgilmore> nirik: ^^^
20:34:18 <jreznik> nirik: just to clarify it not to go through the same discussion tmre
20:34:20 <sgallagh> nirik: What if we already have been? ;-)
20:34:21 <jreznik> tmrw
20:34:25 <tflink> if there is a blocker in RC4 that is not present in RC3, ship RC3 - if some blocker comes up that is present in both before tomorrow, we can deal with that tomorrow
20:34:36 <Viking-Ice> agreed
20:34:42 <sgallagh> tflink: Agreed
20:34:48 <dgilmore> jreznik: tomorrows discussion needs to be did RC4 work or blow up, do we ship RC3 or RC4
20:34:51 <dgilmore> nothing more
20:34:51 <nirik> right
20:35:01 <Viking-Ice> yup
20:35:02 <jreznik> dgilmore: yep
20:35:02 <cmurf> i.e. close the door on more blockers
20:35:09 <jreznik> close the doors
20:35:12 <nirik> +∞
20:35:19 <tflink> -1 to closing the doors on more blockers
20:35:21 <sgallagh> I don't think that's what we said at all.
20:35:29 <drago01> -1
20:35:36 <nirik> we can't have tomorrows meeting today.
20:35:44 <drago01> that makes no sense
20:35:47 <pjones> seriously, this meeting is finished.
20:35:52 <jreznik> nirik: definitely
20:35:55 <sgallagh> We're not. We're just saying that if a blocker comes in, we deal with it tomorrow
20:36:05 <dgilmore> sgallagh: right
20:36:05 <pjones> sgallagh: as we would if we didn't say that.
20:36:06 <sgallagh> As opposed to ignoring it
20:36:06 <cmurf> hello rc5
20:36:17 <jreznik> sgallagh: then we can't say it's go today
20:36:19 <sgallagh> pjones: There appeared to be some confusion
20:36:24 <dgilmore> we would do the same thing if something major turned up after we said it was gold
20:36:36 <jreznik> ok
20:36:37 <dgilmore> anyway lets get this done
20:36:55 <nirik> proposal: end meeting, meet again tomorrow.
20:37:01 <jreznik> wait a moment
20:37:51 <jreznik> #agreed RC3 is Go, but let's test RC4 and decide tomorrow based on the outcome of supplemental testing, finally decide tomorrow 2013-01-10
20:38:05 <jreznik> would it be ok to run that meeting tmrw earlier?
20:38:19 <dgilmore> jreznik: sure
20:38:19 <jreznik> I mean 16:00 utc for example?
20:38:43 <nirik> sure, earlier the better IMHO
20:38:46 <tflink> yep
20:38:47 <cmurf> jreznik: or even earlier
20:38:48 <jreznik> tflink: for qa?
20:38:56 <jreznik> ok
20:39:18 <jwb> so... we're not indefinitely prolonging the meeting then?
20:39:32 <tflink> no
20:39:36 <jreznik> jwb: no, we will have another tmrw
20:39:40 <rbergeron> nirik: i agree
20:39:42 <jwb> oh good.  a semblance of sanity
20:39:52 <rbergeron> jwb: ;)
20:39:52 <pjones> we're not congress.
20:40:07 * nirik mints a trillion dollar coin.
20:40:37 <jreznik> 16:00 utc is the last time I can make
20:40:58 <jreznik> if anyone would be for earlier, I'll be glad :)
20:41:08 <jreznik> but for adamw it would be ...
20:41:15 <tflink> 08:00, I think
20:41:20 <nirik> lets do 16.
20:41:23 <nirik> thats fine.
20:41:24 <jreznik> ok
20:41:30 <Viking-Ice> earlier is fine for me but 16 is fine as well
20:42:29 <jreznik> #agreed to do the final decision tomorrow at 16:00 utc, same channel
20:43:06 <tflink> please help out with poking at rc4 - the more people poking at it, the more confident we can be about the decision to release it or not
20:43:19 <cmurf> ETA rc4?
20:43:24 <jreznik> and the last thing - what do we consider as "tested enough"? completed gnome desktop test matrix?
20:43:43 <jreznik> tflink: yep, I'll do in the announcement
20:43:46 <robatino> all of RC4 is there except scientific KDE spin
20:43:58 <robatino> delta isos are available
20:44:00 <pasik> cmurf: at least I've been testing it already :)
20:44:03 <tflink> at a bare minimum, the desktop spin
20:44:06 <cmurf> ok
20:44:18 <cmurf> and what sort of thing could this fprintd patch blow up?
20:44:27 <cmurf> connecting common or uncommon USB devices?
20:44:34 <cmurf> sneezing?
20:44:40 <jreznik> just a note, KDM does not have fprintd support but in case it will be somewhere in PAM...
20:44:46 <tflink> I'd feel better if there was coverage on the other spins as well and some of the installation test cases
20:44:47 <nirik> same for lightdm
20:44:58 <jreznik> tflink: indeed
20:45:19 <jreznik> could you take care of picking up the install test cases and preparing the special rc4 matrice for that
20:45:29 <jreznik> not to confude people with a full one?
20:45:45 <nirik> and of course any general testing other folks want to do against it to (re)confirm things would be great.
20:45:53 <tflink> actually, how about only pull through the RC2/3 results from things taht don't need to be re-done?
20:46:03 <tflink> I'd rather not make a special matric
20:46:07 <tflink> matrix
20:46:09 <jreznik> makes sense
20:46:35 <Viking-Ice> yup
20:46:40 <jreznik> pull in bits we are going to inherit from RC2/3, what we need to cover - let it blank
20:46:49 <jreznik> but still some note would be great
20:46:59 <Viking-Ice> we could try to reach out to the g+ Fedora community it's pretty active there
20:47:07 <Viking-Ice> for more widespread testing
20:47:19 <tflink> jreznik: sure, an email with the list of test cases?
20:47:25 <jreznik> Viking-Ice: well I'd say QA should cover this without any bigger issues
20:47:33 <jreznik> of course more testing, better
20:47:53 <Viking-Ice> jreznik, this affected more hypervisor then those we ship
20:48:10 <Viking-Ice> even thou it already has been confirmed fixed on hyperv
20:48:16 <jreznik> tflink: an email would be great, thanks
20:48:30 <jreznik> Viking-Ice: I think we are now quite confident it's fixed
20:48:54 <jreznik> anything else?
20:49:27 <jreznik> fyi, in case anythins is going to be screwer up horribly - we could go with Fri Go/No-Go and Thu release
20:50:12 <jreznik> #action jreznik to announce the Go decision and call for testing
20:51:04 <jreznik> #action tflink to pull in test matrices based on RC2/RC3 except the test cases we need to verify for RC4, announce it in email
20:52:26 <jreznik> ok, so I think we are done for now
20:52:35 <jreznik> setting fuse
20:52:43 <jreznik> 3
21:07:59 <nirik> jreznik: were you going to end the meeting? ;)
21:08:10 <jreznik> #endmeeting