17:00:27 <jreznik> #startmeeting F22 Final Go/No-Go meeting
17:00:28 <zodbot> Meeting started Thu May 21 17:00:27 2015 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:29 <jreznik> #meetingname F22 Final Go/No-Go meeting
17:00:29 <zodbot> The meeting name has been set to 'f22_final_go/no-go_meeting'
17:01:07 <jreznik> hey everyone looking for blocker drama!
17:01:15 <nirik> morning
17:01:16 <jreznik> #topic Roll Call
17:01:27 <roshi> .hello roshi
17:01:28 <zodbot> roshi: roshi 'Mike Ruckman' <mruckman@redhat.com>
17:01:36 <kparal> .hello kparal
17:01:37 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
17:01:48 <jwb> i'm kind of around
17:01:51 * satellit listening
17:02:00 * jkurik lurks
17:02:22 * nirik waves to all the go/nogoers
17:02:30 <roshi> o/
17:02:47 <jreznik> #chair nirik roshi kparal jwb
17:02:47 <zodbot> Current chairs: jreznik jwb kparal nirik roshi
17:03:17 * jreznik thinks we can start
17:03:36 <oddshocks> .hello oddshocks
17:03:36 <jreznik> #topic Purpose of this meeting
17:03:36 <zodbot> oddshocks: oddshocks 'David Gay' <dgay@redhat.com>
17:03:38 <jreznik> #info Purpose of this meeting is to see whether or not F22 Final is ready for shipment, according to the release criteria.
17:03:39 <jreznik> #info This is determined in a few ways:
17:03:40 * oddshocks lurking, in other meeting
17:03:41 <jreznik> #info No remaining blocker bugs
17:03:42 <jreznik> #info Release candidate compose is available
17:03:44 <jreznik> #info Test matrices for Final are fully completed
17:03:45 <jreznik> #link http://qa.fedoraproject.org/blockerbugs/milestone/22/final/buglist
17:03:46 <stickster> .hello pfrields
17:03:47 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Installation
17:03:47 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
17:03:48 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Base
17:03:50 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Desktop
17:03:51 <jreznik> #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Server
17:04:10 <sgallagh> ALoha
17:04:22 <dgilmore> hola
17:04:28 <nirik> so I guess first we should do a mini blocker review? since we have 2 proposed blockers.
17:04:34 <dgilmore> nirik: yep
17:04:36 * pwhalen is here
17:04:37 <jreznik> #chair nirik roshi kparal jwb sgallagh dgilmore
17:04:37 <zodbot> Current chairs: dgilmore jreznik jwb kparal nirik roshi sgallagh
17:04:38 <roshi> sure thing
17:04:43 * maxamillion is here
17:04:47 <jreznik> yep, just give me a few seconds :)
17:04:59 * danofsatx is standing by with a PB&J sammich
17:05:03 <jreznik> roshi: may I ask you for blocker review?
17:05:09 <roshi> you got it :)
17:05:14 <jreznik> #topic Current status
17:05:25 <roshi> I'll skip the boiler plate since we all know what blockers are :p
17:05:27 <jreznik> #info we have RC2 ready but two proposed blocker bugs
17:05:35 <jreznik> #topic Mini blocker review
17:05:49 <roshi> first proposal
17:05:49 <roshi> #topic (1221247) LVMError: Process reported exit code 768:   Size is not a multiple of 512. Try using 8063800832 or 8063801344.   Invalid argument for --size: 8063801098b   Error during parsing of command line.
17:05:53 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1221247
17:05:56 <roshi> #info Proposed Blocker, anaconda, NEW
17:06:42 * nirik grumbles about it being reported a week ago and only now becoming a proposed blocker.
17:06:52 <sgallagh> So, given that the average human trying to resize LVM is not going to know what values are safe, I guess I'm at least +1 FE here. I probably wouldn't block on it if it was the Last Blocker.
17:06:54 <kparal> I have discovered it today
17:07:35 <roshi> because there's the potential for data loss, I'm +1 to blocking on this
17:08:01 <kparal> I think LV resizes are pretty common and the number of values for which anaconda crashes is very high. for me +1 blocker, it violates directly referenced criterion
17:08:13 <danofsatx> +1
17:08:14 <maxamillion> sgallagh: what's "FE"?
17:08:20 <roshi> freeze exception
17:08:27 <nirik> so, it's only manual annd if you enter '1234b' ...  right?
17:08:34 <kparal> it wouldn't be that important if there was no data loss involved, but there is
17:08:34 <roshi> which means we'd accept a code change for a fix during the freeze period
17:08:46 <roshi> maxamillion: ^^
17:08:59 <maxamillion> roshi: ah, thanks
17:09:00 <kparal> nirik: if you enter 10.5 GB, it crashes
17:09:17 <nirik> kparal: yeah, I was hoping there would be no dataloss, but it seems we can't be sure of that.
17:09:19 <roshi> kparal was able to suss out the safe values
17:09:30 <kparal> if you enter bytes directly, it might work, if it is dividable by 512
17:09:47 <kparal> see comment 21
17:09:52 <dgilmore> I think here anaconda needs to make sure that the value is rounded down to the nearest safe number
17:10:05 <roshi> that would make sense
17:10:15 * kparal is thrilled about that idea, because he hasn't been sleeping a few hours a day and living on fast food this whole week, oh no...
17:10:18 <kparal> damn
17:10:21 <kparal> wrong clipboard
17:10:22 <jreznik> if there's dataloss involved, I'm more inclined to +1 blocker as this is lottery
17:10:26 <nirik> :)
17:10:27 <roshi> haha
17:10:28 <kparal> <vpodzime> kparal: dlehman are resize actions scheduled before destroy/create actions?
17:10:28 <kparal> <dlehman> generally we do destroy then resize then create
17:10:29 <dgilmore> sadly I think i am +1 to blocker, I can see a lot of people entering different values
17:10:35 <kparal> about that data loss
17:10:44 <nirik> I guess I am slightly +1 blocker... due to the data loss chance
17:10:45 <kparal> the destroy operations are performed first
17:11:28 <jreznik> oh no
17:11:45 <sgallagh> Destroy operations that were requested aren't data loss
17:11:50 <kparal> on the bright side, the fix seems to be a one-liner
17:11:59 <sgallagh> Data loss is "the resize causes the LVM partition to be lost"
17:12:10 <roshi> proposed #agreed - 1221247 - AcceptedBlocker - This bug is a direct violation of the following criterion and has the potential to cause data loss. "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
17:12:21 <nirik> sgallagh: well, other ones could resize before the one that breaks things... leaving you in a weird state.
17:12:32 <kparal> that's somewhat true. but if we destroy the previous system but fail to install a new one, I consider it as breaking the machine
17:12:36 <sgallagh> nirik: weird state != data loss
17:12:48 <kparal> it's data loss in a sense that user can't access his/her data, unless being very skilled
17:12:55 <roshi> yeah
17:12:56 <sgallagh> Nothing has been lost that was expected to remain, as far as I can tell
17:12:59 <jreznik> kparal: aha, I got it now
17:13:05 <nirik> sgallagh: true.
17:13:44 <roshi> I mean, something being "technically" possible doesn't mean it's generally possible (getting to your data)
17:13:46 * jreznik saw data loss and it worked as red flag for bull for me today after day spent with kernel issue
17:13:49 <sgallagh> So I'm still -1 blocker on this. I'd probably have been +1 if we were discussing this two weeks ago.
17:13:58 <sgallagh> But I'm definitely +1 FE since we're rebuilding anyway
17:14:28 * jreznik is now more 0, or even -1 after clarification
17:14:38 <roshi> votes now?
17:14:42 <kparal> it's still directly violating the criterion
17:14:50 <roshi> yeah
17:14:50 <nirik> kparal: well, it does 'attempt'
17:15:03 <kparal> but not correctly, it's not rounded properly
17:15:25 <sgallagh> (My point being that if vpodzime's patch doesn't completely fix this, I wouldn't slip for it)
17:15:41 <kparal> "This means that if the installer offers mechanisms for resizing storage volumes, then it must run the appropriate resizing tool with the appropriate parameters for the resize the user chooses."
17:15:47 * dgilmore is ack for the propossed
17:16:41 <kparal> ack from me
17:16:44 <dgilmore> sgallagh: it either violates the criteria or not
17:16:51 <nirik> yeah, ack, sadly.
17:17:02 <roshi> #agreed - 1221247 - AcceptedBlocker - This bug is a direct violation of the following criterion and has the potential to cause data loss. "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
17:17:02 <jreznik> ack
17:17:03 <sgallagh> dgilmore: We've fudged it before if the impact was not enormous.
17:17:16 <dgilmore> there is not wiggle room for, if it was a week ago I would have said yes it is a blocker but not now
17:17:17 <sgallagh> I guess I'll just hope the patch works
17:17:18 <oddshocks> ack
17:17:19 <jwb> that's a weird criteria
17:17:25 <jwb> "correctly attempt" ?
17:17:31 <nirik> sgallagh: me too.
17:17:39 <nirik> jwb: yeah, that seems odd to me as well...
17:17:40 <roshi> I think we all will
17:17:45 <kparal> jwb: there's a longer explanation at https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Storage_volume_resize
17:17:50 <dgilmore> jwb: probably should be "correctly execute"
17:17:54 <kparal> under expander
17:18:13 <roshi> ready for the next one?
17:18:16 <sgallagh> Actually, under the current wording, it's not a violation
17:18:32 <sgallagh> Because it passes reasonable data to lvm.
17:18:41 <sgallagh> But let's move on
17:19:10 <roshi> last proposed blocker
17:19:11 <roshi> #topic (1223332) ext4 corruption on kernel 4.0.2
17:19:11 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1223332
17:19:11 <roshi> #info Proposed Blocker, kernel, MODIFIED
17:19:40 <kparal> roshi: should I secretarialize the bugs?
17:19:43 * nirik waits for jwb to explain what is known.
17:19:46 <jwb> this bug is terrible because it was opened based on a phoronix article, and then people piled on
17:19:47 <roshi> that'd be great
17:19:49 <jwb> anyway
17:19:52 <kparal> roshi: ok
17:19:54 <jwb> there's two bugs here
17:20:06 <roshi> I was just going to do it after the meeting, so thanks :)
17:20:08 <kparal> jwb: I'm sorry I opened it in a hurry just to have a bug to track this
17:20:40 <jwb> 1) there is an ext4 bug that can hit in very rare circumstances that likely doesn't actually impact anyone in reality.  it was fixed in 4.0.3 and so is covered in 4.0.4-301
17:20:47 <jwb> kparal, it isn't your fault
17:20:49 <jreznik> jwb: softopedia, phoronix is not always bad
17:21:05 <jwb> jreznik, now is not the time to argue with me about phoronix
17:21:38 <roshi> lol
17:21:45 <jwb> 2) the more serious bug is an raid0 issue that will discard blocks incorrectly.  that was also brought back into 4.0.2 via a stable backport and a patch is queued to fix it upstream
17:21:57 <jwb> 4.0.4-301 contains that patch
17:22:27 <jwb> since mkfs.* tools like to issue discard, it can cause weirdness like petr saw on raid0 installs
17:22:46 <nirik> or people running fstrim.timer or the like.
17:23:00 <mattdm> jwb: fair to describe this as "two unrelated (but widely reported together) bugs
17:23:01 <jwb> correct.  it is also possible to hit in raid0 setups with large (4k) I/O scenarios that aren't aligned to 4k
17:23:04 <drago01> (or mount with "discard")
17:23:13 * dgilmore does have fstrim.timer enabled on a raid1 with ssd's
17:23:19 <jwb> i said raid0
17:23:38 <dgilmore> jwb: right, it is only raid0 correct?
17:23:43 <jwb> afaik, yes
17:23:45 <nirik> anyhow, I am +1 blocker here. We want to prevent dataloss no matter how corner case.
17:23:52 <maxamillion> +1
17:23:55 <kparal> that confirms our findings, pschindl had issues only with raid0
17:24:01 <maxamillion> dataloss scares me
17:24:02 <dgilmore> I am +1 blocker also
17:24:04 <jwb> mattdm, frankly, i'd ignore the ext4 bug.
17:24:06 <sgallagh> +1 blocker
17:24:07 <roshi> +1
17:24:15 <kparal> +1
17:24:21 <maxamillion> also, random side note ... does that effect the 4.1.x kernel at all?
17:24:24 <mattdm> nirik: ehhhh, there's an infinite number of corner cases which cause data loss -- let's be careful with that
17:24:27 <mattdm> jwb: ack
17:24:39 <jwb> maxamillion, yes.  i fixed the same issue with the same patch in rawhide this morning
17:24:48 <maxamillion> jwb: you're my hero
17:24:52 <nirik> mattdm: well, ok, let me say I agree with the critera: "All known bugs that can cause corruption of user data must be fixed or documented at Common F22 bugs."
17:24:53 <mattdm> jwb: does raid0 bug happen regardless of filesystem?
17:24:54 <jwb> i am a patch monkey
17:24:58 <jwb> mattdm, it can, yes
17:25:02 <maxamillion> jwb: so 4.1.0-0.rc4.git0.1.fc23.x86_64 has the fix?
17:25:04 <mattdm> jwb++
17:25:08 <jwb> maxamillion, no
17:25:09 <maxamillion> jwb++
17:25:09 <zodbot> maxamillion: Karma for jwboyer changed to 4:  https://badges.fedoraproject.org/tags/cookie/any
17:25:14 <maxamillion> jwb: awww, sadface
17:25:22 <jwb> maxamillion, 4.1.0-0.rc4.git1.1.fc23
17:25:28 <maxamillion> jwb: rgr, thanks
17:25:37 <jwb> which afaik is still building
17:25:43 <sgallagh> jwb++
17:25:43 <zodbot> sgallagh: Karma for jwboyer changed to 5:  https://badges.fedoraproject.org/tags/cookie/any
17:25:55 <roshi> proposed #agreed - 1223332 - AcceptedBlocker - This bug is a direct violation of the following Final Release Criterion: "All known bugs that can cause corruption of user data must be fixed or documented at Common F22 bugs."
17:26:00 <sgallagh> ack
17:26:02 <jreznik> ack
17:26:06 <oddshocks> ack
17:26:08 <dgilmore> ack
17:26:20 <jwb> as an added bonus, you also get the FE approved i915 flicker fix
17:26:26 <roshi> #agreed - 1223332 - AcceptedBlocker - This bug is a direct violation of the following Final Release Criterion: "All known bugs that can cause corruption of user data must be fixed or documented at Common F22 bugs."
17:26:46 <roshi> want to go through the accepted blockers?
17:27:09 <kparal> there's one discussion worthy, liveusb-creator
17:27:21 <jreznik> yep
17:27:43 <maxamillion> that the liveusb-creator/anaconda/systemd one?
17:27:45 * roshi pulls it up
17:28:10 <maxamillion> 487168
17:28:21 <roshi> #topic (1166650) [abrt] liveusb-creator: connection.py:651:call_blocking:DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
17:28:22 <maxamillion> bah, sorry
17:28:25 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1166650
17:28:28 <roshi> #info Accepted Blocker, liveusb-creator, ASSIGNED
17:28:31 <mattdm> I don't quite understand how this one is a blocker -- isn't the bug in the media creation tool rather than in media creation?
17:28:51 <roshi> it is
17:28:54 <nirik> mattdm: it is, but we have a criterion that all 'recommended' tools for this have to work
17:29:03 <roshi> and this is our tool to do it
17:29:04 <dgilmore> mattdm: its a blocker for release
17:29:05 <sgallagh> FYI, the kernel -301 build just concluded
17:29:07 <nirik> so, one action we could take here is to not recommend this tool anymore
17:29:16 <sgallagh> /me has been monitoring it
17:29:20 <dgilmore> mattdm: but the fix has to go to f20 f21 f22 and rawhide
17:29:41 <kparal> this does not block compose, just to make it clear. it blocks the release itself (the announcement, I guess)
17:30:08 <dgilmore> kparal: right, without the bug fixed we can not make teh release available
17:30:10 <mattdm> So it could go out as an update, we just want to make sure that update is available pre-tuesday.
17:30:11 <roshi> so the fix could get pushed at the same time as the announcement if need be
17:30:20 <dgilmore> mattdm: correct
17:30:23 * mattdm is cool with this
17:30:32 <kparal> maybe lmacken will make it work soon, but it's possible that he will not. liveusb-creator has been problematic for a very long time. maybe it's time to retire it
17:30:48 <mattdm> fallback plan is to remove it from the docs, right?
17:30:58 <kparal> i.e. not include it in our official docs as a supported tool
17:31:05 <dgilmore> mattdm: its about making sure that people can make working usb live/install sticks
17:31:06 <oddshocks> My liveusb-creator is dd ;)
17:31:06 <nirik> right.
17:31:09 <Southern_Gentlem> and commonbugs not to use it
17:31:15 <nirik> oddshocks: simple and effective. ;)
17:31:35 <sgallagh> We also now have gnome-multi-writer, which is dd+verification
17:31:42 * satellit_e the (dd) option does work in every DE but workstation
17:31:43 <nirik> so, I am fine with waiting more, but we should decide/track it before release.
17:31:54 <roshi> for sure
17:32:05 <Southern_Gentlem> and livecd-iso-to-disk
17:32:13 <roshi> who wants an action item to keep track of that
17:32:14 <roshi> ?
17:32:24 <kparal> should we decide now whether we're fine with removing it from docs if it is not fixed in time?
17:32:27 <jreznik> btw. we will have new liveusb-creator
17:32:30 <roshi> I've already pinged luke about it, so I can - if that jives with everyone
17:32:59 <oddshocks> +1
17:32:59 <roshi> +1 to just removing it from reccommended if it doesn't work in time
17:33:06 <oddshocks> +1 to that, too
17:33:06 <jreznik> see https://fedorahosted.org/marketing-team/ticket/197
17:33:11 <nirik> +1 to that.
17:33:20 <roshi> which "that?"
17:33:24 <nirik> jreznik: can't see it.
17:33:42 <nirik> sorry, +1 to removing it from the list of recommended methods if it's not fixed by release time.
17:33:49 <roshi> np :)
17:34:04 <dgilmore> +! to removing from recommended methods
17:34:15 <roshi> #action roshi to sync up with lmacken regardling liveusb-creator
17:34:21 <jreznik> nirik: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/USB-boot-creator/usb-boot-creator-degnomified.png
17:34:31 <jreznik> nirik: and https://fedoraproject.org/wiki/Changes/LiveUsbCreatorFacelift
17:34:39 <nirik> ok.
17:34:44 <roshi> I think that's all on the blocker side of things
17:34:44 <sgallagh> I'm in favor of just removing it from recommended methods, period
17:35:30 <jreznik> I pinged mbriza but did not get answer how it's related to the old one but eta is f23, we can recommend it again later once we have new frontend (and fixes in backend)
17:35:31 <danofsatx> +1 sgallagh
17:35:51 <dgilmore> jreznik: :)
17:36:41 <jreznik> but with current state I'm +1 to sgallagh proposal
17:37:02 <roshi> works for me
17:37:12 <maxamillion> +1 sgallagh
17:37:13 <nirik> well, it seems poor to me to tell luke at the last minute that his work on it was wasted.
17:37:19 <kparal> is there a benefit, rather than giving lmacken some time?
17:37:21 <jreznik> https://git.fedorahosted.org/cgit/liveusb-creator.git/log/?h=feature/new-ui
17:37:27 <dgilmore> nirik: indeed
17:37:29 <kparal> as nirik said
17:37:42 <roshi> he's working on it - I say give him time
17:37:46 * satellit_e what other way do we use for installer USB from windows?
17:37:51 <jreznik> kparal: or we can ask mbriza to take a look too - as I said I pinged him but I did not insist on him
17:38:06 <nirik> satellit_e: there's some dd like things for windows... rawrite or whatever.
17:38:10 <kparal> are the docs frozen on a Go decision, or can we still adjust them during the following week?
17:38:15 <jreznik> can we do the call later Monday? what documentation recommends it?
17:38:26 <jreznik> kparal: it's question what docs
17:38:31 <Southern_Gentlem> monday is a holiday
17:38:37 <nirik> note FYI, monday is a holiday in the us
17:38:39 <maxamillion> nirik has a good point though
17:38:40 <jreznik> Southern_Gentlem: ah, you're right
17:38:53 * nirik isn't sure what docs.
17:38:55 * stickster sorry for not being here sooner, was detained
17:38:58 * jreznik already skipped Monday for one product release
17:39:05 * mattdm nominates jreznik to do all the work since he's not in the us
17:39:11 <sgallagh> stickster: Wait, how'd you get out of the handcuffs?
17:39:13 <stickster> We should give Luke some time -- we can make the call on removal by Monday COB or even Tuesday morning
17:39:16 * dgilmore will be afk monday as I am a single dad and will have a child to occupy
17:39:16 * maxamillion throws a shoe at stickster
17:39:30 <nirik> it's the wiki. ;)
17:39:37 <maxamillion> (Austin Powers style)
17:39:50 <nirik> 18:05:24 <adamw> 'officially supported methods' is a link to the 'how to create USB sticks' page, which documents the supported methods, of which luc is one.
17:40:06 <jreznik> maxamillion: well, seems like finishing will be on me if we will plan to release on Tuesday :)))
17:40:32 <jreznik> it it's only wiki, then I can edit it if we don't have solution on Monday
17:40:36 <nirik> so, we can adjust that anytime. yes.
17:40:45 <kparal> jreznik: certain wiki docs, not sure about docs from documentation team
17:40:55 <jreznik> kparal: pinging right now
17:41:14 <stickster> Hopefully this gives Luke a respite from pings at least so he can jam on the code :-)
17:41:20 <jreznik> (not sure I'll get answer anytime soon)
17:41:21 <nirik> yeah.
17:41:34 <nirik> shall we move on?
17:42:10 <jreznik> wow, cool - the new LUC frontend is QML based!!! like, like!
17:42:18 <dgilmore> lets move on
17:42:33 <roshi> yeah
17:42:36 <jreznik> ok
17:42:54 <jreznik> #topic Test Matrices coverage
17:43:11 <jreznik> let's take a quick look how much tests are covered
17:43:24 <kparal> hmmm, the coverage is somewhat lacking I'm afraid
17:43:25 <jreznik> might be another part of the decision if we want to play heroes or not
17:43:27 <roshi> with a new kernel in RC3, I don't know that they amount to much
17:43:39 <roshi> the current results, I mean
17:43:53 <kparal> with new kernel and new anaconda parts, many of the test cases should be re-tested, if we want to be safe
17:43:58 * nirik nods.
17:44:37 <kparal> and there are still a lot of white cells in the current RC2 matrices, summary is here https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Summary
17:45:46 <jreznik> what are the most important test cases that are blank and should be filled even with RC2 to make RC3 transition easier?
17:45:46 <kparal> unfortunately there are at least a few test cases which we either haven't tested since Beta, or even at all. I'm not sure we can do it in a day with all those RC3 changes, if we decide to postpone the decision to tomorrow. we can certainly try.
17:46:25 <kparal> we have this comparison tool: https://www.happyassassin.net/testcase_stats/22/
17:46:53 <kparal> QA:Testcase_Arabic_Language_Install was never tested
17:47:02 <kparal> QA:Testcase_Anaconda_updates.img_via_installation_source was never tested
17:47:11 <dgilmore> kparal: with a RC3 we will have to postpone the decision until tomorrow
17:47:29 <sgallagh> dgilmore: That's not true.
17:47:40 <sgallagh> We could just decide that tomorrow isn't enough time and announce the slip
17:47:48 <kparal> the usual problems are SAS and FCoE
17:47:52 <kparal> not tested
17:47:54 <sgallagh> Which it sounds to me is what kparal is really asking for.
17:47:58 <roshi> i'll put in the request here soon
17:48:01 <sgallagh> kparal: SAS I actually just tested today
17:48:10 <kparal> sgallagh: oh great
17:48:13 <sgallagh> Well, SAS backing my fwraid anyway
17:48:44 <dgilmore> sgallagh: right
17:48:45 <kparal> if we have 24 hours more to test, I think it could be done and fully tested, but it will require a lot of work
17:48:49 <sgallagh> kparal: So I'm comfortable with that one at least
17:49:09 <jreznik> so kparal, how much chance you give we will be able to test it all tomorrow with as much help from anyone willing to help?
17:49:21 <jreznik> ok, answer is there
17:49:38 <kparal> unless we get stuck on more bugs like today
17:49:46 <jreznik> dgilmore: does 24 hours still work for you or we need it earlier as the last time?
17:49:48 <mattdm> If people are champing at the bit to test overnight, I won't stop anyone, but I'm comfortable with also encouraging people to spend time with their families and/or pets, sleep, etc.
17:49:56 <kparal> fedup, fwraid and anaconda resize amounted to a lot of "wasted" time
17:50:05 <jreznik> mattdm: sleep is overrated!
17:50:29 * mattdm has a slip apologia message already drafted
17:50:49 * nirik is ok either way. Happy to help test and help those testing tonight if we want to try
17:51:06 <sgallagh> mattdm: https://xkcd.com/1484/
17:51:11 <dgilmore> jreznik: realistically the latest we can get it on mirrors and ship next week is saturday morning. but I do not know how that combined with Monday beinga  US public holiday will effect mirroring
17:51:23 <sgallagh> Ditto; If the plan is to try for tomorrow, I'll be helping.
17:51:31 * satellit I have some time to help but it is a holiday here
17:51:40 <mattdm> sgallagh: heh yes.
17:52:14 <nirik> dgilmore: I wouldn't think too much... most mirrors have all that automated.
17:52:28 <mattdm> mirrors are probably not keen on tuesday-after-holiday anyway — we'll be releasing with the set of mirrors that are fully automated and which do not have glitches with that
17:52:32 <mattdm> which is hopefully all of them
17:52:45 * mattdm notes that the mirror at Harvard still seems to be working, knock on wood
17:52:55 <nirik> we haven't really had problems with mirroring on recent releases. We have a lot more BW on master mirrors, etc.
17:53:27 <jreznik> dgilmore: and I really don't want to force you to do it on Saturday... just saying for others to consider it...
17:53:54 <dgilmore> mattdm: right, it may or may not be a full contingent
17:53:56 <jreznik> nirik: Alpha/Beta I saw some false hits on GA
17:54:00 <nirik> so, it sounds like folks are willing to try testing a rc3 as soon as it appears and revisit tomorrow same time?
17:54:16 <nirik> jreznik: hum?
17:54:16 <roshi> yeah
17:54:36 <jreznik> nirik: before all links worked on web...
17:54:45 <dgilmore> jreznik: if people get the testing done, I will get it on the mirrors saturday
17:54:47 <jreznik> do we want same time or a bit earlier?
17:55:02 <roshi> compose request is in
17:55:08 <dgilmore> jreznik: I will also have to work monday night on a public holiday to do the final tasks as well
17:55:11 <jreznik> it's question for folks in EU - I'm willing to be available on 17 utc
17:55:18 <nirik> jreznik: we did have some gitches, but hopefully not for final. ;)
17:55:34 <fedorauser|36512> thank you guys for your great effort
17:55:41 <jreznik> dgilmore: any help needed, ping me...
17:55:45 <mattdm> dgilmore: can some of those final tasks be shared out?
17:55:47 <mattdm> jreznik++
17:55:47 <zodbot> mattdm: Karma for jreznik changed to 12:  https://badges.fedoraproject.org/tags/cookie/any
17:56:09 <dgilmore> mattdm: not easily.
17:56:14 <dgilmore> mattdm: they are not too huge
17:56:18 <dgilmore> making torrents
17:56:23 <dgilmore> and flipping the bits
17:56:35 <jreznik> dgilmore++
17:56:35 <zodbot> jreznik: Karma for ausil changed to 9:  https://badges.fedoraproject.org/tags/cookie/any
17:56:38 <mattdm> dgilmore k
17:56:51 <sgallagh> dgilmore: If you toss me the torrent files, I'll mirror them
17:57:01 <sgallagh> Or rather, seed them
17:57:07 <dgilmore> mattdm: nirik could do them, but he is on the same boat
17:57:10 <jreznik> so - the same time or earlier? we will have a lot of to do, so I'd say let's stick with 17:00 UTC
17:57:30 <nirik> I'd be happy to also
17:57:31 <jreznik> dgilmore: coul peter help too?
17:57:48 <dgilmore> jreznik: not without help
17:57:54 <jreznik> ok
17:57:58 <roshi> please spot check that compose request and make sure there wasn't anything else we needed in RC3
17:58:02 <dgilmore> jreznik: the process is pretty poorly documented :(
17:58:03 * nirik knows how the torrents work better now since i rebuilt the machine. ;)
17:58:05 * roshi didn't think there was anything else
17:58:14 <dgilmore> jreznik: not sure nirik could do it either
17:58:31 <nirik> dgilmore: I think I can now. I redid the torrent machine as rhel7 and rebuilt in ansible. :)
17:58:33 <Southern_Gentlem> guys as much as i would love to see this go out the door push and give LUC sometime to be fixed and to do the testing without burning yourselves out
17:58:51 <dgilmore> nirik: :) its kinda weird and really does not work right
17:58:52 <mattdm> dgilmore: we need to fix that. but I know you know that. :)
17:59:04 <nirik> dgilmore: I know. :) beleive me I know.
17:59:05 <kparal> roshi: we might need to repeat the previous builds in RC3 compose request again because we still haven't pushed them stable
17:59:19 * nirik is doing stable push now.
17:59:33 <dgilmore> mattdm: yeah, we really should make the .torrent files at compose time.
17:59:33 <stickster> jreznik++
17:59:33 <zodbot> stickster: Karma for jreznik changed to 13:  https://badges.fedoraproject.org/tags/cookie/any
17:59:39 <dgilmore> or drop torrents
17:59:53 <kparal> nirik: should we point you to some of those that can be pushed stable now?
18:00:04 <nirik> kparal: some of those which?
18:00:11 <kparal> builds, pending stable
18:00:32 <dgilmore> kparal: all builds in RC1 and RC2 that can go stable should be
18:00:40 <jreznik> dgilmore: it might be late to touch all websites to remove torrents there
18:00:42 <kparal> ok
18:00:49 <dgilmore> jreznik: :P indeed
18:00:54 <nirik> dgilmore: no they aren't.
18:01:09 <nirik> kparal: there's a request in ticket from roshi as per the process. thats what I am looking at.
18:02:06 <nirik> https://fedorahosted.org/rel-eng/ticket/6120#comment:25
18:02:08 <maxamillion> nirik: will this one go to stable today also? https://admin.fedoraproject.org/updates/FEDORA-2015-8557/xorg-x11-drivers-7.7-14.fc22 (I'm not that familiar with the process)
18:02:27 <maxamillion> nirik: heh, nvm ... it's right there in the ticket
18:02:42 <nirik> yes
18:02:50 <jreznik> ok, we're on top of the hour - so moving on, we can resolve this in the ticket
18:03:08 <jreznik> to fulfil process...
18:03:10 <mattdm> ok, so, decision is to defer decision until tomorrow morning?
18:03:10 <jreznik> #topic Go/No-Go decision
18:03:16 * nirik is somewhat confused about the PackageKit update, but can ask out of band
18:03:31 <jreznik> mattdm: say no-go today and schedule another go/no-go meeting for the same time tomorrow
18:03:32 <dgilmore> releng is no go right now
18:03:51 <nirik> no go now, revisit tomorrow.
18:03:59 <dgilmore> checking again tomorrow is good
18:04:01 <roshi> sorry, got pulled away
18:04:03 * mattdm nods
18:04:29 <oddshocks> +1 to no go now, check again tomorrow
18:04:57 <roshi> sounds like that's the plan
18:05:12 <jreznik> proposal #agreed Fedora 22 Final status is no-go by Release Engineering, QA and Development; we will revisit on special Go/No-Go meeting on Friday 2015-05-22 17:00 UTC
18:05:35 <stickster> :-( but understandable. No one likes a slip, but the important thing is to know why.
18:05:36 <sgallagh> jreznik: +1
18:06:24 <dgilmore> ack
18:06:26 <oddshocks> ack
18:06:34 <roshi> ack
18:06:43 <jwb> i hate it when we frown at slips
18:07:01 <kparal> ack
18:07:04 <maxamillion> jwb: +1
18:07:08 <mattdm> jwb++
18:07:09 <jwb> the alternative is to screw over our users.  there's nothing to frown about
18:07:17 <roshi> true
18:07:18 <jreznik> #agreed Fedora 22 Final status is no-go by Release Engineering, QA and Development; we will revisit on special Go/No-Go meeting on Friday 2015-05-22 17:00 UTC
18:07:37 <jreznik> and our users is everything we have
18:07:51 <jreznik> (except fun on go/no-go)
18:08:21 * mattdm saves draft of definitely-non-frowny magazine post
18:08:30 <jreznik> ok, thanks for coming! and let's set alarm clock for early testing in the morning :)
18:08:31 * mattdm goes back to working on release announcement
18:08:48 * mattdm will help test too. :)
18:09:08 <jreznik> dgilmore: btw spot already merged my patches to multi boot media creator upstream, so we can build MATE_Compiz
18:09:30 <jreznik> once we have final ISOs
18:09:37 <dgilmore> jreznik: cool.
18:10:06 <jreznik> #action jreznik to announce decision
18:10:11 <jreznik> #topic Open floor
18:10:19 <kparal> there's one more noteworthy fedup bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1223735
18:10:29 <kparal> fedup upgrades don't work with non-updated F21
18:10:30 <jreznik> ok, thanks kparal
18:10:33 <kparal> because of systemd
18:10:55 <kparal> it does not violate our criteria, becuase we require fedora to be fully updated before fedup is run
18:11:00 <jreznik> I'd say upgrades has to be always performed on the updated system
18:11:08 <kparal> but I'm just pointing it out, because it could bite some of our users
18:11:24 <kparal> jreznik: there's nothing forcing it, not even recommending it. outside of our wiki
18:11:29 <pschindl_wfh> Hi all. So how did it go?
18:11:31 <kparal> so, just a heads up
18:11:57 <jreznik> kparal: so let's make sure it's written somewhere
18:12:03 <kparal> pschindl_wfh: still open floor. and more work to do tomorrow -> RC3
18:12:04 <jreznik> pschindl_wfh: it didn't GO
18:12:08 <nirik> pschindl_wfh: we are going to try and be heros and test rc3 over the next day
18:12:27 <kparal> jreznik: it can be fixed with a fedup spec file change, if we convince wwoods
18:13:23 <pschindl_wfh> ok. Yet another busy day ahead :)
18:13:46 * lkiesow thanks everyone for their hard work
18:13:53 <jreznik> kparal: how?
18:14:28 <kparal> jreznik: require latest systemd
18:14:44 <kparal> the problem is caused by an old systemd
18:14:46 <jreznik> ah, I got it now
18:14:51 <jreznik> thanks
18:15:03 <jreznik> kparal++
18:15:04 <zodbot> jreznik: Karma for kparal changed to 1:  https://badges.fedoraproject.org/tags/cookie/any
18:15:20 <jreznik> for all that work on release validation!
18:15:46 <jreznik> ok, so is there anything else?
18:16:18 <jreznik> readiness meeting is in 44 minutes, same channel
18:16:57 <sgallagh> I recommend that everyone who is going to be testing tonight try to get some rest while the compose is running.
18:17:02 <roshi> since we're going to be testing overnight, if you don't have other responsibilities - I'd suggest wandering off to do something relaxing for a bit while the compose runs
18:17:05 <sgallagh> It's going to be a long day after that
18:17:21 <roshi> great minds, eh sgallagh? ;)
18:17:22 <jreznik> #info F22 readiness meeting is 19:00 UTC #fedora-meeting-2
18:17:27 <sgallagh> roshi: Ours too
18:17:41 <jreznik> sgallagh: I already had one Red Bull :)
18:18:05 <roshi> lol
18:18:24 <jreznik> so I'm full of energy now, no rest time :)))
18:18:29 <jreznik> 3...
18:21:36 <jreznik> 2...
18:22:09 <roshi> thanks for running this jreznik
18:22:26 <maxamillion> +1 thanks jreznik
18:22:30 <jreznik> thanks for help roshi with blocker review!
18:22:46 <jreznik> 1...
18:22:50 <roshi> np np
18:23:02 <jreznik> and thanks everyone for coming and helping with testing and release
18:23:05 <jreznik> #endmeeting