17:00:27 #startmeeting F22 Final Go/No-Go meeting 17:00:28 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:29 #meetingname F22 Final Go/No-Go meeting 17:00:29 The meeting name has been set to 'f22_final_go/no-go_meeting' 17:01:07 hey everyone looking for blocker drama! 17:01:15 morning 17:01:16 #topic Roll Call 17:01:27 .hello roshi 17:01:28 roshi: roshi 'Mike Ruckman' 17:01:36 .hello kparal 17:01:37 kparal: kparal 'Kamil Páral' 17:01:48 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 o/ 17:02:47 #chair nirik roshi kparal jwb 17:02:47 Current chairs: jreznik jwb kparal nirik roshi 17:03:17 * jreznik thinks we can start 17:03:36 .hello oddshocks 17:03:36 #topic Purpose of this meeting 17:03:36 oddshocks: oddshocks 'David Gay' 17:03:38 #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 #info This is determined in a few ways: 17:03:40 * oddshocks lurking, in other meeting 17:03:41 #info No remaining blocker bugs 17:03:42 #info Release candidate compose is available 17:03:44 #info Test matrices for Final are fully completed 17:03:45 #link http://qa.fedoraproject.org/blockerbugs/milestone/22/final/buglist 17:03:46 .hello pfrields 17:03:47 #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Installation 17:03:47 stickster: pfrields 'Paul W. Frields' 17:03:48 #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Base 17:03:50 #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Desktop 17:03:51 #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Final_RC2_Server 17:04:10 ALoha 17:04:22 hola 17:04:28 so I guess first we should do a mini blocker review? since we have 2 proposed blockers. 17:04:34 nirik: yep 17:04:36 * pwhalen is here 17:04:37 #chair nirik roshi kparal jwb sgallagh dgilmore 17:04:37 Current chairs: dgilmore jreznik jwb kparal nirik roshi sgallagh 17:04:38 sure thing 17:04:43 * maxamillion is here 17:04:47 yep, just give me a few seconds :) 17:04:59 * danofsatx is standing by with a PB&J sammich 17:05:03 roshi: may I ask you for blocker review? 17:05:09 you got it :) 17:05:14 #topic Current status 17:05:25 I'll skip the boiler plate since we all know what blockers are :p 17:05:27 #info we have RC2 ready but two proposed blocker bugs 17:05:35 #topic Mini blocker review 17:05:49 first proposal 17:05:49 #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 #link https://bugzilla.redhat.com/show_bug.cgi?id=1221247 17:05:56 #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 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 I have discovered it today 17:07:35 because there's the potential for data loss, I'm +1 to blocking on this 17:08:01 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 +1 17:08:14 sgallagh: what's "FE"? 17:08:20 freeze exception 17:08:27 so, it's only manual annd if you enter '1234b' ... right? 17:08:34 it wouldn't be that important if there was no data loss involved, but there is 17:08:34 which means we'd accept a code change for a fix during the freeze period 17:08:46 maxamillion: ^^ 17:08:59 roshi: ah, thanks 17:09:00 nirik: if you enter 10.5 GB, it crashes 17:09:17 kparal: yeah, I was hoping there would be no dataloss, but it seems we can't be sure of that. 17:09:19 kparal was able to suss out the safe values 17:09:30 if you enter bytes directly, it might work, if it is dividable by 512 17:09:47 see comment 21 17:09:52 I think here anaconda needs to make sure that the value is rounded down to the nearest safe number 17:10:05 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 damn 17:10:21 wrong clipboard 17:10:22 if there's dataloss involved, I'm more inclined to +1 blocker as this is lottery 17:10:26 :) 17:10:27 haha 17:10:28 kparal: dlehman are resize actions scheduled before destroy/create actions? 17:10:28 generally we do destroy then resize then create 17:10:29 sadly I think i am +1 to blocker, I can see a lot of people entering different values 17:10:35 about that data loss 17:10:44 I guess I am slightly +1 blocker... due to the data loss chance 17:10:45 the destroy operations are performed first 17:11:28 oh no 17:11:45 Destroy operations that were requested aren't data loss 17:11:50 on the bright side, the fix seems to be a one-liner 17:11:59 Data loss is "the resize causes the LVM partition to be lost" 17:12:10 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 sgallagh: well, other ones could resize before the one that breaks things... leaving you in a weird state. 17:12:32 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 nirik: weird state != data loss 17:12:48 it's data loss in a sense that user can't access his/her data, unless being very skilled 17:12:55 yeah 17:12:56 Nothing has been lost that was expected to remain, as far as I can tell 17:12:59 kparal: aha, I got it now 17:13:05 sgallagh: true. 17:13:44 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 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 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 votes now? 17:14:42 it's still directly violating the criterion 17:14:50 yeah 17:14:50 kparal: well, it does 'attempt' 17:15:03 but not correctly, it's not rounded properly 17:15:25 (My point being that if vpodzime's patch doesn't completely fix this, I wouldn't slip for it) 17:15:41 "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 ack from me 17:16:44 sgallagh: it either violates the criteria or not 17:16:51 yeah, ack, sadly. 17:17:02 #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 ack 17:17:03 dgilmore: We've fudged it before if the impact was not enormous. 17:17:16 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 I guess I'll just hope the patch works 17:17:18 ack 17:17:19 that's a weird criteria 17:17:25 "correctly attempt" ? 17:17:31 sgallagh: me too. 17:17:39 jwb: yeah, that seems odd to me as well... 17:17:40 I think we all will 17:17:45 jwb: there's a longer explanation at https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Storage_volume_resize 17:17:50 jwb: probably should be "correctly execute" 17:17:54 under expander 17:18:13 ready for the next one? 17:18:16 Actually, under the current wording, it's not a violation 17:18:32 Because it passes reasonable data to lvm. 17:18:41 But let's move on 17:19:10 last proposed blocker 17:19:11 #topic (1223332) ext4 corruption on kernel 4.0.2 17:19:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=1223332 17:19:11 #info Proposed Blocker, kernel, MODIFIED 17:19:40 roshi: should I secretarialize the bugs? 17:19:43 * nirik waits for jwb to explain what is known. 17:19:46 this bug is terrible because it was opened based on a phoronix article, and then people piled on 17:19:47 that'd be great 17:19:49 anyway 17:19:52 roshi: ok 17:19:54 there's two bugs here 17:20:06 I was just going to do it after the meeting, so thanks :) 17:20:08 jwb: I'm sorry I opened it in a hurry just to have a bug to track this 17:20:40 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 kparal, it isn't your fault 17:20:49 jwb: softopedia, phoronix is not always bad 17:21:05 jreznik, now is not the time to argue with me about phoronix 17:21:38 lol 17:21:45 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 4.0.4-301 contains that patch 17:22:27 since mkfs.* tools like to issue discard, it can cause weirdness like petr saw on raid0 installs 17:22:46 or people running fstrim.timer or the like. 17:23:00 jwb: fair to describe this as "two unrelated (but widely reported together) bugs 17:23:01 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 (or mount with "discard") 17:23:13 * dgilmore does have fstrim.timer enabled on a raid1 with ssd's 17:23:19 i said raid0 17:23:38 jwb: right, it is only raid0 correct? 17:23:43 afaik, yes 17:23:45 anyhow, I am +1 blocker here. We want to prevent dataloss no matter how corner case. 17:23:52 +1 17:23:55 that confirms our findings, pschindl had issues only with raid0 17:24:01 dataloss scares me 17:24:02 I am +1 blocker also 17:24:04 mattdm, frankly, i'd ignore the ext4 bug. 17:24:06 +1 blocker 17:24:07 +1 17:24:15 +1 17:24:21 also, random side note ... does that effect the 4.1.x kernel at all? 17:24:24 nirik: ehhhh, there's an infinite number of corner cases which cause data loss -- let's be careful with that 17:24:27 jwb: ack 17:24:39 maxamillion, yes. i fixed the same issue with the same patch in rawhide this morning 17:24:48 jwb: you're my hero 17:24:52 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 jwb: does raid0 bug happen regardless of filesystem? 17:24:54 i am a patch monkey 17:24:58 mattdm, it can, yes 17:25:02 jwb: so 4.1.0-0.rc4.git0.1.fc23.x86_64 has the fix? 17:25:04 jwb++ 17:25:08 maxamillion, no 17:25:09 jwb++ 17:25:09 maxamillion: Karma for jwboyer changed to 4: https://badges.fedoraproject.org/tags/cookie/any 17:25:14 jwb: awww, sadface 17:25:22 maxamillion, 4.1.0-0.rc4.git1.1.fc23 17:25:28 jwb: rgr, thanks 17:25:37 which afaik is still building 17:25:43 jwb++ 17:25:43 sgallagh: Karma for jwboyer changed to 5: https://badges.fedoraproject.org/tags/cookie/any 17:25:55 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 ack 17:26:02 ack 17:26:06 ack 17:26:08 ack 17:26:20 as an added bonus, you also get the FE approved i915 flicker fix 17:26:26 #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 want to go through the accepted blockers? 17:27:09 there's one discussion worthy, liveusb-creator 17:27:21 yep 17:27:43 that the liveusb-creator/anaconda/systemd one? 17:27:45 * roshi pulls it up 17:28:10 487168 17:28:21 #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 bah, sorry 17:28:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=1166650 17:28:28 #info Accepted Blocker, liveusb-creator, ASSIGNED 17:28:31 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 it is 17:28:54 mattdm: it is, but we have a criterion that all 'recommended' tools for this have to work 17:29:03 and this is our tool to do it 17:29:04 mattdm: its a blocker for release 17:29:05 FYI, the kernel -301 build just concluded 17:29:07 so, one action we could take here is to not recommend this tool anymore 17:29:16 /me has been monitoring it 17:29:20 mattdm: but the fix has to go to f20 f21 f22 and rawhide 17:29:41 this does not block compose, just to make it clear. it blocks the release itself (the announcement, I guess) 17:30:08 kparal: right, without the bug fixed we can not make teh release available 17:30:10 So it could go out as an update, we just want to make sure that update is available pre-tuesday. 17:30:11 so the fix could get pushed at the same time as the announcement if need be 17:30:20 mattdm: correct 17:30:23 * mattdm is cool with this 17:30:32 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 fallback plan is to remove it from the docs, right? 17:30:58 i.e. not include it in our official docs as a supported tool 17:31:05 mattdm: its about making sure that people can make working usb live/install sticks 17:31:06 My liveusb-creator is dd ;) 17:31:06 right. 17:31:09 and commonbugs not to use it 17:31:15 oddshocks: simple and effective. ;) 17:31:35 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 so, I am fine with waiting more, but we should decide/track it before release. 17:31:54 for sure 17:32:05 and livecd-iso-to-disk 17:32:13 who wants an action item to keep track of that 17:32:14 ? 17:32:24 should we decide now whether we're fine with removing it from docs if it is not fixed in time? 17:32:27 btw. we will have new liveusb-creator 17:32:30 I've already pinged luke about it, so I can - if that jives with everyone 17:32:59 +1 17:32:59 +1 to just removing it from reccommended if it doesn't work in time 17:33:06 +1 to that, too 17:33:06 see https://fedorahosted.org/marketing-team/ticket/197 17:33:11 +1 to that. 17:33:20 which "that?" 17:33:24 jreznik: can't see it. 17:33:42 sorry, +1 to removing it from the list of recommended methods if it's not fixed by release time. 17:33:49 np :) 17:34:04 +! to removing from recommended methods 17:34:15 #action roshi to sync up with lmacken regardling liveusb-creator 17:34:21 nirik: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/USB-boot-creator/usb-boot-creator-degnomified.png 17:34:31 nirik: and https://fedoraproject.org/wiki/Changes/LiveUsbCreatorFacelift 17:34:39 ok. 17:34:44 I think that's all on the blocker side of things 17:34:44 I'm in favor of just removing it from recommended methods, period 17:35:30 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 +1 sgallagh 17:35:51 jreznik: :) 17:36:41 but with current state I'm +1 to sgallagh proposal 17:37:02 works for me 17:37:12 +1 sgallagh 17:37:13 well, it seems poor to me to tell luke at the last minute that his work on it was wasted. 17:37:19 is there a benefit, rather than giving lmacken some time? 17:37:21 https://git.fedorahosted.org/cgit/liveusb-creator.git/log/?h=feature/new-ui 17:37:27 nirik: indeed 17:37:29 as nirik said 17:37:42 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 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 satellit_e: there's some dd like things for windows... rawrite or whatever. 17:38:10 are the docs frozen on a Go decision, or can we still adjust them during the following week? 17:38:15 can we do the call later Monday? what documentation recommends it? 17:38:26 kparal: it's question what docs 17:38:31 monday is a holiday 17:38:37 note FYI, monday is a holiday in the us 17:38:39 nirik has a good point though 17:38:40 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 stickster: Wait, how'd you get out of the handcuffs? 17:39:13 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 it's the wiki. ;) 17:39:37 (Austin Powers style) 17:39:50 18:05:24 '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 maxamillion: well, seems like finishing will be on me if we will plan to release on Tuesday :))) 17:40:32 it it's only wiki, then I can edit it if we don't have solution on Monday 17:40:36 so, we can adjust that anytime. yes. 17:40:45 jreznik: certain wiki docs, not sure about docs from documentation team 17:40:55 kparal: pinging right now 17:41:14 Hopefully this gives Luke a respite from pings at least so he can jam on the code :-) 17:41:20 (not sure I'll get answer anytime soon) 17:41:21 yeah. 17:41:34 shall we move on? 17:42:10 wow, cool - the new LUC frontend is QML based!!! like, like! 17:42:18 lets move on 17:42:33 yeah 17:42:36 ok 17:42:54 #topic Test Matrices coverage 17:43:11 let's take a quick look how much tests are covered 17:43:24 hmmm, the coverage is somewhat lacking I'm afraid 17:43:25 might be another part of the decision if we want to play heroes or not 17:43:27 with a new kernel in RC3, I don't know that they amount to much 17:43:39 the current results, I mean 17:43:53 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 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 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 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 we have this comparison tool: https://www.happyassassin.net/testcase_stats/22/ 17:46:53 QA:Testcase_Arabic_Language_Install was never tested 17:47:02 QA:Testcase_Anaconda_updates.img_via_installation_source was never tested 17:47:11 kparal: with a RC3 we will have to postpone the decision until tomorrow 17:47:29 dgilmore: That's not true. 17:47:40 We could just decide that tomorrow isn't enough time and announce the slip 17:47:48 the usual problems are SAS and FCoE 17:47:52 not tested 17:47:54 Which it sounds to me is what kparal is really asking for. 17:47:58 i'll put in the request here soon 17:48:01 kparal: SAS I actually just tested today 17:48:10 sgallagh: oh great 17:48:13 Well, SAS backing my fwraid anyway 17:48:44 sgallagh: right 17:48:45 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 kparal: So I'm comfortable with that one at least 17:49:09 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 ok, answer is there 17:49:38 unless we get stuck on more bugs like today 17:49:46 dgilmore: does 24 hours still work for you or we need it earlier as the last time? 17:49:48 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 fedup, fwraid and anaconda resize amounted to a lot of "wasted" time 17:50:05 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 mattdm: https://xkcd.com/1484/ 17:51:11 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 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 sgallagh: heh yes. 17:52:14 dgilmore: I wouldn't think too much... most mirrors have all that automated. 17:52:28 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 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 we haven't really had problems with mirroring on recent releases. We have a lot more BW on master mirrors, etc. 17:53:27 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 mattdm: right, it may or may not be a full contingent 17:53:56 nirik: Alpha/Beta I saw some false hits on GA 17:54:00 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 jreznik: hum? 17:54:16 yeah 17:54:36 nirik: before all links worked on web... 17:54:45 jreznik: if people get the testing done, I will get it on the mirrors saturday 17:54:47 do we want same time or a bit earlier? 17:55:02 compose request is in 17:55:08 jreznik: I will also have to work monday night on a public holiday to do the final tasks as well 17:55:11 it's question for folks in EU - I'm willing to be available on 17 utc 17:55:18 jreznik: we did have some gitches, but hopefully not for final. ;) 17:55:34 thank you guys for your great effort 17:55:41 dgilmore: any help needed, ping me... 17:55:45 dgilmore: can some of those final tasks be shared out? 17:55:47 jreznik++ 17:55:47 mattdm: Karma for jreznik changed to 12: https://badges.fedoraproject.org/tags/cookie/any 17:56:09 mattdm: not easily. 17:56:14 mattdm: they are not too huge 17:56:18 making torrents 17:56:23 and flipping the bits 17:56:35 dgilmore++ 17:56:35 jreznik: Karma for ausil changed to 9: https://badges.fedoraproject.org/tags/cookie/any 17:56:38 dgilmore k 17:56:51 dgilmore: If you toss me the torrent files, I'll mirror them 17:57:01 Or rather, seed them 17:57:07 mattdm: nirik could do them, but he is on the same boat 17:57:10 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 I'd be happy to also 17:57:31 dgilmore: coul peter help too? 17:57:48 jreznik: not without help 17:57:54 ok 17:57:58 please spot check that compose request and make sure there wasn't anything else we needed in RC3 17:58:02 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 jreznik: not sure nirik could do it either 17:58:31 dgilmore: I think I can now. I redid the torrent machine as rhel7 and rebuilt in ansible. :) 17:58:33 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 nirik: :) its kinda weird and really does not work right 17:58:52 dgilmore: we need to fix that. but I know you know that. :) 17:59:04 dgilmore: I know. :) beleive me I know. 17:59:05 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 mattdm: yeah, we really should make the .torrent files at compose time. 17:59:33 jreznik++ 17:59:33 stickster: Karma for jreznik changed to 13: https://badges.fedoraproject.org/tags/cookie/any 17:59:39 or drop torrents 17:59:53 nirik: should we point you to some of those that can be pushed stable now? 18:00:04 kparal: some of those which? 18:00:11 builds, pending stable 18:00:32 kparal: all builds in RC1 and RC2 that can go stable should be 18:00:40 dgilmore: it might be late to touch all websites to remove torrents there 18:00:42 ok 18:00:49 jreznik: :P indeed 18:00:54 dgilmore: no they aren't. 18:01:09 kparal: there's a request in ticket from roshi as per the process. thats what I am looking at. 18:02:06 https://fedorahosted.org/rel-eng/ticket/6120#comment:25 18:02:08 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 nirik: heh, nvm ... it's right there in the ticket 18:02:42 yes 18:02:50 ok, we're on top of the hour - so moving on, we can resolve this in the ticket 18:03:08 to fulfil process... 18:03:10 ok, so, decision is to defer decision until tomorrow morning? 18:03:10 #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 mattdm: say no-go today and schedule another go/no-go meeting for the same time tomorrow 18:03:32 releng is no go right now 18:03:51 no go now, revisit tomorrow. 18:03:59 checking again tomorrow is good 18:04:01 sorry, got pulled away 18:04:03 * mattdm nods 18:04:29 +1 to no go now, check again tomorrow 18:04:57 sounds like that's the plan 18:05:12 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 :-( but understandable. No one likes a slip, but the important thing is to know why. 18:05:36 jreznik: +1 18:06:24 ack 18:06:26 ack 18:06:34 ack 18:06:43 i hate it when we frown at slips 18:07:01 ack 18:07:04 jwb: +1 18:07:08 jwb++ 18:07:09 the alternative is to screw over our users. there's nothing to frown about 18:07:17 true 18:07:18 #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 and our users is everything we have 18:07:51 (except fun on go/no-go) 18:08:21 * mattdm saves draft of definitely-non-frowny magazine post 18:08:30 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 dgilmore: btw spot already merged my patches to multi boot media creator upstream, so we can build MATE_Compiz 18:09:30 once we have final ISOs 18:09:37 jreznik: cool. 18:10:06 #action jreznik to announce decision 18:10:11 #topic Open floor 18:10:19 there's one more noteworthy fedup bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1223735 18:10:29 fedup upgrades don't work with non-updated F21 18:10:30 ok, thanks kparal 18:10:33 because of systemd 18:10:55 it does not violate our criteria, becuase we require fedora to be fully updated before fedup is run 18:11:00 I'd say upgrades has to be always performed on the updated system 18:11:08 but I'm just pointing it out, because it could bite some of our users 18:11:24 jreznik: there's nothing forcing it, not even recommending it. outside of our wiki 18:11:29 Hi all. So how did it go? 18:11:31 so, just a heads up 18:11:57 kparal: so let's make sure it's written somewhere 18:12:03 pschindl_wfh: still open floor. and more work to do tomorrow -> RC3 18:12:04 pschindl_wfh: it didn't GO 18:12:08 pschindl_wfh: we are going to try and be heros and test rc3 over the next day 18:12:27 jreznik: it can be fixed with a fedup spec file change, if we convince wwoods 18:13:23 ok. Yet another busy day ahead :) 18:13:46 * lkiesow thanks everyone for their hard work 18:13:53 kparal: how? 18:14:28 jreznik: require latest systemd 18:14:44 the problem is caused by an old systemd 18:14:46 ah, I got it now 18:14:51 thanks 18:15:03 kparal++ 18:15:04 jreznik: Karma for kparal changed to 1: https://badges.fedoraproject.org/tags/cookie/any 18:15:20 for all that work on release validation! 18:15:46 ok, so is there anything else? 18:16:18 readiness meeting is in 44 minutes, same channel 18:16:57 I recommend that everyone who is going to be testing tonight try to get some rest while the compose is running. 18:17:02 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 It's going to be a long day after that 18:17:21 great minds, eh sgallagh? ;) 18:17:22 #info F22 readiness meeting is 19:00 UTC #fedora-meeting-2 18:17:27 roshi: Ours too 18:17:41 sgallagh: I already had one Red Bull :) 18:18:05 lol 18:18:24 so I'm full of energy now, no rest time :))) 18:18:29 3... 18:21:36 2... 18:22:09 thanks for running this jreznik 18:22:26 +1 thanks jreznik 18:22:30 thanks for help roshi with blocker review! 18:22:46 1... 18:22:50 np np 18:23:02 and thanks everyone for coming and helping with testing and release 18:23:05 #endmeeting