17:00:15 #startmeeting F26 Final Go/No-Go meeting 17:00:15 Meeting started Thu Jul 6 17:00:15 2017 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:15 The meeting name has been set to 'f26_final_go/no-go_meeting' 17:00:17 #meetingname F26 Final Go/No-Go meeting 17:00:17 The meeting name has been set to 'f26_final_go/no-go_meeting' 17:00:43 it's been a loooong time, hey everyone 17:00:49 morning. 17:00:50 #topic Roll Call 17:00:54 hello jreznik 17:01:00 hey jreznik. Hope you have been good. :) 17:01:15 .hello adamwill 17:01:16 adamw: adamwill 'Adam Williamson' 17:01:17 brb, call of nature 17:01:37 #chair nirik kparal adamw 17:01:37 Current chairs: adamw jreznik kparal nirik 17:01:37 * satellit listening 17:01:46 .hello roshi 17:01:47 roshi: roshi 'Mike Ruckman' 17:02:17 nirik: yeah, it was a good time but you know, all best times were Fedora :) 17:02:22 #chair roshi 17:02:22 Current chairs: adamw jreznik kparal nirik roshi 17:02:32 .hello mattdm 17:02:32 mattdm: mattdm 'Matthew Miller' 17:02:33 let's wait a minute 17:02:37 welcome back jreznik :) 17:02:44 * tenk listening 17:03:27 * jreznik is covering for jkurik (this and next week, let's hope it will be just this one) 17:03:57 #topic Purpose of this meeting 17:04:24 #info Purpose of this meeting is to see whether or not F26 Final is ready for shipment, according to the release criteria. 17:04:26 #info This is determined in a few ways: 17:04:27 #info No remaining blocker bugs 17:04:29 #info Release candidate compose is available 17:04:30 #info Test matrices for Final are fully completed 17:04:49 yay 17:04:56 oh wait that's just wishful thinking :) 17:05:09 :) 17:05:12 #topic Current status 17:05:44 .fas x3mboy 17:05:46 x3mboy: x3mboy 'Eduard Lucena' 17:05:58 #info RC 1.5 is available for release validation 17:06:51 also RC 1.4 17:06:52 #info we have 8 accepted blockers (of which 4 are VERIFIED, 4 ON_QA) and 5 proposed blockers 17:06:58 we have the potential choice of releasing either (or neither) 17:07:03 .hello mohanboddu 17:07:04 mboddu: mohanboddu 'Mohan Boddu' 17:07:09 but not both :p 17:07:17 #info RC 1.4 is available too - we have the potential choice of releasing either (or neither) 17:07:21 yes, that might be going a bit too far :P 17:07:44 more is better! 17:07:45 #link http://qa.fedoraproject.org/blockerbugs/milestone/26/final/buglist 17:08:06 #link https://fedoraproject.org/wiki/Test_Results:Fedora_26_RC_1.5_Summary?rd=Test_Results:Current_Summary 17:08:25 any other status updates for now? 17:08:46 that about covers it, I think 17:09:00 ok 17:09:31 let's move on to the "mini" blocker review 17:09:33 #topic Mini blocker review 17:09:41 roshi: may I ask you? 17:09:45 sure thing 17:09:47 #info The bugs up for review today are available at: 17:09:47 #link http://qa.fedoraproject.org/blockerbugs/current 17:09:47 #info The criteria for release blocking bugs can be found at: 17:09:47 #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria 17:09:49 #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria 17:09:52 #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria 17:10:09 as stated before, 5 to go through 17:10:12 first up: 17:10:13 #topic (1467368) totem doesn't work in VMs under Wayland 17:10:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1467368 17:10:13 #info Proposed Blocker, clutter, NEW 17:11:13 you know my view here :) 17:11:58 lol 17:12:33 so this is on vm's using spice/qxl only right? 17:12:41 In short: -1 blocker because impact is relatively minor (happens in limited situations, easy workaround by x11 fallback) compared to impact of further slip 17:12:43 I don't see much more details from 2017-07-03 blocker review meeting 17:13:19 yeah, -1 blocker (what mattdm said) 17:13:20 doesn't work on VMPlayer on windows, which isn't good 17:13:23 on bare metal, this probably shouldn't happen, because if you use safe graphics mode (nomodeset), you get X11 17:13:30 from the last comment, at least 17:13:59 it's still quite embarrassing for new release reviews, though 17:14:00 nirik: no, it affects virtio, qxl and vga, whether with SPICE or VNC 17:14:05 that seems pretty bad 17:14:33 i'm not convinced there's no affected bare metal case, but we at least haven't found one yet... 17:15:08 kparal: yeah, that's the case i'm most worried about. though I suspect reviewers mostly use virtualbox. 17:15:12 or vmware, but...see later! 17:15:15 I'd be for sure +1 if the whole instance failed to boot under these configs, instead of just some apps not working 17:15:26 virtualbox "works" :) 17:16:02 I'm -1 because of limited scope, with the current info. but workstation WG should be able to object here, if any one of them is present...? 17:16:36 * roshi is +1, because it *does* violate the criterion 17:16:39 they are about 100 meters from me right now -- want me to go ping someone? 17:17:16 someone to voice their opinions would be nice, I believe 17:17:23 yeah 17:17:26 yeah, it'd be good to have their input 17:17:27 * jreznik can wait 17:17:51 in an ideal world i'd kinda *like* to block on this, but given we're a long way behind the intended release cycle i could go with a -1 17:18:00 christian says they don't want to block on that but he'll work to get a fix fast post release 17:18:10 oh, i did ask yesterday if a fix for this was likely to be forthcoming quickly and it sounded like 'no' 17:18:24 thanks 17:18:31 * roshi pretends to exist in an ideal world :p 17:19:15 i think we can plausibly reject it for being configuration-specific and relatively workaround...able 17:19:17 if workstation wg is ok with it, then I'm also -1 and if we can get fix soon... 17:19:31 obviously needs to be CommonBugs'ed 17:19:47 roshi: in an ideal world, all this stuff would just work :) 17:19:47 the workaround for a vm being X11 or a different video player 17:20:06 kparal: yeah 17:20:12 how many default video players do we ship? :) 17:20:26 * mattdm wonders how common this will *actually* be IRL 17:20:34 jreznik: firefox! 17:20:43 proposed #agreed - RHBZ#1467368 - The general consensus is that this bug can be worked around and only affects specific configurations and is not considered a blocker. Work-arounds will be annotated on the Common Bugs page. 17:20:57 kparal: no, there's 'GDK_BACKEND=x11 totem' (or whatever it is) too 17:21:07 ack 17:21:12 * nirik is +1FE if we slip and get a fix. ;) 17:21:14 ack 17:21:15 ack 17:21:18 #agreed - RHBZ#1467368 - The general consensus is that this bug can be worked around and only affects specific configurations and is not considered a blocker. Work-arounds will be annotated on the Common Bugs page. 17:21:18 ack 17:21:24 next up: 17:21:25 #topic (1461283) [abrt] kamoso: QByteArray::QByteArray(): kamoso killed by signal 11 17:21:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=1461283 17:21:31 #info Proposed Blocker, kamoso, NEW 17:21:43 this seems to happen only if there is no camera 17:21:53 which doesn't seem serious enough to block on, though it does look a bit bad 17:21:53 -1 since it just fails when the needed hardware isn't there 17:21:55 -1 for all the reasons, but adam's is most compelling so I go with that one 17:22:04 -1 also ditto 17:22:05 -1 here, it's not nice to end with crash but camera app without any camera... 17:22:24 * jreznik is looking on the core right now 17:22:29 s/core/code 17:22:56 proposed #agreed - RHBZ#1461283 - While it would be great to handle this failure case in a more graceful way, it doesn't qualify as a blocker. 17:23:29 ack 17:23:45 ack 17:23:46 ack 17:23:51 #agreed - RHBZ#1461283 - While it would be great to handle this failure case in a more graceful way, it doesn't qualify as a blocker. 17:24:00 #topic (1468239) discover crashes in setupFlatpakInstallations() 17:24:00 #link https://bugzilla.redhat.com/show_bug.cgi?id=1468239 17:24:01 #info Proposed Blocker, plasma-discover, NEW 17:24:48 so, this one really *ought* to be a blocker 17:24:48 KDE users: what is 'discover'? 17:24:51 how common is discover? people use it alot? 17:24:55 package installer thingy, i think. 17:25:12 isn't dnfdragora the recommended package installer thingy? 17:25:14 pretty clear blocker, yeah 17:25:31 they have multiple, so some of them might crash :) 17:25:43 anyone test the updated package? 17:25:45 Can I be -1 on *that* alone? :( 17:25:59 mattdm: well, no, since the criterion says all apps that are included should run without crashing. 17:26:00 mattdm: you can be -1 for whatever reasons you like :p 17:26:06 it doesn't matter if some of them are redundant with each other. 17:26:12 * satellit dnfdragora worked for me... 17:26:17 seems like similar case as with kamoso - this seems to crash due to some misconfiguration of the system just it crashes instead of failing in a nice way 17:26:19 the problem is, KDE has a bunch of redundant apps 17:26:33 and few testers 17:26:33 upstream has suggested a patch... 17:26:39 looking on the patch... https://cgit.kde.org/discover.git/commit/?id=e062f0e946489d8c10c656379b229de1c117e21b 17:26:51 if dnfdragora can be used instead, and we really want to release asap, I can imagine waiving this one and accepting it as F27 blocker 17:26:53 if we've tested the patch, I can be fine with a 0Day update 17:26:54 roshi: At the very least, I think in the future we need to change the "all apps must work" release criteria for KDE. 17:27:03 kparal: There. That. 17:27:06 i'd rather we find a way to test the fking thing properly 17:27:15 from #fedora-kde - ‎[17:05] ‎<‎CRCinAU‎>‎ if you chmod 777 /var/lib/flatpak, then it works ;) 17:27:20 ugh 17:27:21 yeah 17:27:21 i.e. get the kde folks to help; it's *supposed* to be the case that it's not QA's job to do all of the testing any more 17:27:35 adamw: +1 to that 17:27:39 (who on earth wrote the app to assume it could make dirs in /var/lib anyway?) 17:27:45 kde uses dnfdragora now? interesting. 17:28:03 used it for a while, iirc (it came up last cycle I think) 17:28:48 https://bugzilla.redhat.com/buglist.cgi?component=plasma-discover&list_id=7558879&product=Fedora 17:28:56 adamw: flatpak? 17:28:57 what is used in KDE as the default update manager? (what app should pop up a notification about updates and install them?) 17:29:08 oof 17:29:09 is that dnfdragora? 17:29:14 all of them :p 17:29:15 kparal: i asked that on kde@ a few weeks back 17:29:29 i think the answer is that the KDE applet is supposed to do update notification 17:29:35 dnfdragora is for arbitrary package installation 17:29:41 and discover is for...i dunno, installing flatpaks? crashing? 17:29:44 kparal: the thing that pops up app installs is a packagekit based thing 17:29:48 yes notifies but have to go to menus to start dnfdragora 17:29:55 so what handles actually downloading and installing the updates? 17:29:56 satellit: no, it can install them too. 17:29:57 from bugzilla, it looks like it is for crashing 17:30:15 * nirik doesn't like the number of private bugs there 17:30:21 I think this crashes in F25 17:30:24 iow, if discover is broken, can KDE users still automatically get updates? 17:30:30 so this looks more like underlying flatpak issue as it seems like flatpak_get_system_installations returns null and it crashes as it derefferences null pointer 17:30:31 kparal: yes, I believe so. 17:30:32 nirik: that's abrt being careful, right? 17:30:37 does it work in other DEs? 17:30:49 mattdm: yes 17:30:54 s/careful/paranoid 17:31:02 but it means it could be explotable/whatever... in theory 17:31:08 abrt lives in a cabin in the woods that's off the grid 17:31:16 the shed is full of canned tuna 17:31:21 * satellit cinnamon and mate I think 17:31:22 typing away on it's manual typewriter. 17:31:22 kparal: are we sure this works in other DEs? 17:31:36 jreznik: what "this"? 17:31:39 (or other software install tools using flatpaks) 17:31:39 define 'this' 17:31:44 GNOME Software works fine. 17:32:00 i don't think any other desktop has anything that does anything with flatpaks. Xfce is the only other release blocking desktop and it uses dnfdragora, i think. 17:32:02 Cinnamon works fine too 17:32:05 kparal: well, for me it looks like flatpak issue, discover just fails due to wrong handling of null pointer 17:32:10 Sorry to interrupt 17:32:18 jreznik: presumably it doesn't do that on GNOME, or Software handles it. 17:32:22 yep. gnome-software works fine on Xfce also FWIW 17:32:30 adamw: but it should not work :) 17:32:34 x3mboy: no problem, thanks for the info 17:32:35 jreznik: but I didn't try to install any flatpak, it just crashes when you start it on a default desktop 17:32:46 It looks like there are a whole bunch of unresolved crashes in this app in F25 17:32:47 it's trying to figure out the flatpak environment, i think. 17:32:59 mattdm: i don't know if it was in KDE live in F25... 17:33:00 * adamw looks 17:33:21 so here's the thing 17:33:23 flatpak is pretty new 17:33:23 we don't have time to respin 17:33:29 we can't plausibly argue this doesn't violate the criterion as written 17:33:37 so we either follow the process and accept it as a blocker and slip 17:33:50 or just decide as a group we don't care and ignore it 17:34:13 or we say that it should be a blocker but we're waiving it on the basis that it was tested too late and we have schedule considerations. which is technically not supposed to happen, but i think we've done something like it before. if we're gonna do that, though, we really ought to write it down somewhere. 17:34:20 and we should certainly immediately accept it as an F27 Final blocker. 17:34:29 for sure 17:34:32 I would like to push the "ignore it" button here. Basically, this is a problem because there is an underlying problem int the process. 17:34:38 i mean 17:34:44 let's not beat about the bush here 17:34:44 I'd be ok with that second plan. 17:34:48 we have slipped in similar situations before 17:34:55 yep 17:35:07 * roshi is +1 Blocker here 17:35:11 we are considering not doing so because certain downstreams whose name starts in 'red' and ends in 'hat' really want f26 shipped on something that vaguely resembles the schedule 17:35:17 if not just because that's what this process is *for* 17:35:17 i think it's better to be clear about that than not 17:35:38 also we are pressing up against the f27 schedule of ours... 17:35:49 I'm okay with making it an F27 blocker, but if we get to the F27 beta and there isn't movement on this and other KDE blockers we need to look at whether we have the resources as a proejct to make KDE release blocking 17:35:58 that, too, and f27 is supposed to have a whole lot of stuff happening in it, and it also is supposed to stay vaguely on schedule 17:36:02 ie, mass rebuild is next week, features we should spend time looking at we aren't because we are still testing f26 etc 17:36:14 mattdm: i don't think the issue is with getting things fixed (or worked around) once they're found, it's with finding them. 17:36:31 continuing my thoughts: 17:36:59 it *is* true that Fedora is supposed to be hybrid time/quality-based (not entirely 'release on time however good it is', and not entirely 'don't release until it's good enough no matter how late it is') 17:37:03 mattdm: we as a QA have troubles keeping KDE release blocking. we definitely need help from KDE team, or these situations will occur frequently 17:37:19 so i think that's a reasonable basis for making this kind of call, for a bug that was discovered far too late in a cycle that's already delayed 17:37:22 adamw: okay, I'm willing to believe that. Let's take that bigger conversation to somewhere else though 17:37:29 i'd just like us to be clear that that's what we're doing, and write down some kind of policy for it 17:37:36 it's all about having kind of strategy how to make sure we run full validation at least once early in the cycle 17:37:38 adamw: thanks, yes. *that's* the button I want to push :) 17:37:39 +1 to that 17:37:57 to the "write down some kind of policy for it" 17:38:02 (and it's not only for kde but for everything that's not that popular in qa ;-) 17:38:18 I do want to be clear that it's not *just* ye olde downstream sponsor that's affected by slips 17:38:33 We are affected just for ourselves as it starts running into the next cycle 17:38:45 well, *everyone* is impacted by the quality of our releases 17:38:48 yes, having a 'schedule, late, sorry' clause we can use thats actually in the critera would be good 17:38:51 and it sucks for our upstreams who expect to have fedora deliver their stuff to users quickly 17:39:04 and we've recently been referenced as the distro that will slip if it needs to 17:39:15 slip, but not forever 17:39:16 or I saw something like that on reddit at some point 17:39:22 roshi: which is a compliment 17:39:26 it is 17:39:46 I don't want to lose that impression people have, if we can help it 17:40:10 because, overall, I see that as a huge net positive for us 17:40:14 another option is not delay all editions just because one has issues. but that means lot of technical issues to solve, I imagine 17:40:18 * nirik wonders if we kept slipping if we could have f26 come out after f27. ;) 17:40:25 lol 17:40:28 that'd be a first 17:40:28 mattdm, why is KDE blocking when it's not an official Fedora product 17:40:32 nirik: nitpick: it shouldn't be in the criteria but in the process docs somewhere (all the SOPs) 17:40:43 historical reasons. ;) 17:40:43 nb: basically because it always has been. 17:40:55 adamw: sure, whatever... whereever it is... 17:41:04 anyhow, some one want to make a proposal so we can move on? 17:41:07 but the 'flavor / variant / product' set and the 'release-blocking' set have never really been intended to be the same, i don't think... 17:41:11 mattdm, I would think the same reasoning that applies to ambassadors being asked not to provide the multi-desktop live images would apply to not letting one of the spins block the release 17:41:13 okay, i'll bite 17:41:16 nb: it still has quite a few users even we try to hide it from them :) baaaad users! 17:41:19 I would, but I don't know what we're deciding 17:41:39 nb I think that's a compelling point. But let's save it because it's part of a big discussion 17:41:39 but it's OT now - let's focus on blocker status 17:42:05 -1 blocker, or +1 blocker but +1 ship it anyway 17:42:08 fwiw, I think we can only say "this doesn't block" for N+1 releases 17:42:28 it's kinda shady to decide that on the fly when everyone has been under the impression that something is blocking 17:42:46 my $.02 anyways, I guess 17:42:52 proposed #agreed 1468239 - AcceptedBlocker (F27 Final) - this bug clearly violates the criteria and ought to be an F26 Final blocker. However, it was discovered very late in a release cycle that's already delayed, and we believe the best course for Fedora's hybrid time/quality-based release schedule is to have a process for waiving cases like this to block the *next* release, as we have occasionally done before. Accordingly, this is accepted as an 17:42:52 F27 blocker, and we will ensure a formal policy is drafted soon. 17:43:00 ...something like that, i'll trim some characters. 17:43:04 ack 17:43:29 ack 17:43:30 ack to the wording 17:43:35 ack 17:43:35 ack 17:43:38 adamw: can we block one milestone before? 17:43:39 ack 17:43:49 so in this case make from f26 final -> f27 beta 17:43:51 thanks for summing up adamw 17:43:54 jreznik: well, we could, but i'm not sure it'd be appropriate (this only violates a Final criterion) 17:43:55 well, the test is a final test 17:44:10 which milestone it blocks for is based on the criterion violated 17:44:14 it should of course be on common bugs, etc. 17:44:20 adamw: this could be a policy - if something is transferred, it has to be fixed one milestone earlier 17:44:30 true 17:44:31 ! 17:44:33 we don't want to be in the same situation in 6 months from now 17:44:40 * mattdm doesn't want to write this policy now 17:44:45 but keeping track of that might be a pain 17:44:46 Can I write an opinion? 17:44:46 right, move on? 17:44:53 x3mboy: sure, chime in 17:44:53 x3mboy: go for it 17:45:06 ack, let's move on 17:45:10 adamw: you can do the full #agreed, then I'll move to the next after x3mboy 17:45:14 WG and SIGs normally complain about don't being taking into account 17:45:20 #agreed 1468239 - AcceptedBlocker (F27 Final) - Clearly violates criteria and should be an F26 Final blocker. However, discovered very late in a release cycle that's already delayed, and we believe the best course for Fedora's hybrid time/quality-based release schedule is to have a process for waiving cases like this to block the *next* release, as we have occasionally done before. Accepted as an F27 blocker. We will draft a formal policy soon. 17:45:24 KDE guys more than anyone 17:45:34 And the reason it's things like this 17:45:40 i'd say a condition of being taken into account is to help with testing. 17:45:41 not to be too blunt about it, but they need to show up to the meetings 17:45:47 If this happens in Gnome, we probably block the Release 17:45:49 But, Ok 17:45:49 roshi: well, I'm here 17:45:52 and th testing 17:45:57 Was just an opinion of things I read before 17:46:00 x3mboy, yes, but Gnome is part of an official fedora product 17:46:00 Move on 17:46:03 kde is a spin 17:46:14 jreznik: sure 17:46:18 the test process is not a secret. we announce all the composes that are nominated for testing. we document the process thoroughly, we sit here on IRC to help out anyone who wants to contribute, we write little helper things like relval and testcase_stats. 17:46:22 we really need people to *help test*. 17:46:27 nb: as it was said, we have more blocking deliverables than products 17:46:33 but I doubt you'll be all complainy about hte process since you were here and involved 17:46:37 I digress, though 17:46:40 next bug? 17:46:44 nest bug 17:46:57 yep 17:46:58 #topic (1467599) Unable to start domain: the CPU is incompatible with host CPU: Host CPU does not provide required features: svm 17:46:58 adamw: well, I did in the past as much as possible... but what works for me, doesn't work for kparal and vice versa (I can crash gnome with one click :D) 17:47:01 #link https://bugzilla.redhat.com/show_bug.cgi?id=1467599 17:47:02 let's move on 17:47:03 #info Proposed Blocker, qemu, MODIFIED 17:47:28 thanks to adam for some awesome work on making it possible to make a choice here! 17:47:35 mattdm: for the record, Discover is on the F25 KDE live, but doesn't crash on startup. 17:48:01 and now we get to make the choice :) 17:48:03 adamw: flatpak support is new 17:48:08 adamw++ 17:48:08 roshi: Karma for adamwill changed to 30 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:48:23 adamw: 1.5 boxes on amd cpu worked fine for you? 17:48:39 kparal: yep. 17:48:55 so we haven't seen any negative reports about the qemu change 17:49:00 so, this bug was found in RC-1.4 and fixed (really, worked around) in RC-1.5 17:49:00 so, any reason not to +1 blocker this and take 1.5? 17:49:14 Do we feel overall-good about RC 1.5 testing? 17:49:28 kparal: how much smoke testing did you get done on RC-1.5? I haven't had a chance to look 17:49:31 The Cloud Base image works and Workstation installs in VMWare, is all *I* know :) 17:49:34 openQA tests all passed, but openQA doesn't hit all images 17:49:38 testing looks solid for 1.5 17:49:42 I booted all the composes, but didn't install them 17:49:44 mattdm: eh, you got Workstation to boot in VMware? What voodoo di you use? 17:49:46 aiui at least 17:49:50 also tried burning cds 17:49:50 ugh not vmware 17:49:56 kparal: that's fine, if it boots i'm happy 17:50:00 no voodoo at all. i just had that on my mnid 17:50:03 yeah, installer starts up 17:50:11 kvm-qemu via virt-manager 17:50:16 do we know if any significant images are missing compared to RC-1.4? (or showed up?) 17:50:18 sorry for the false excitement 17:50:19 * adamw checks 17:51:00 adamw: AFAIK, no new images or no failed images from 1.4 to 1.5 17:51:31 mboddu: did the arm minimal image that pbrobinson was concerned about fail again? 17:51:45 In RC5, not RC4: 17:51:45 {('robotics', 'live', 'i386'), ('minimal', 'raw-xz', 'aarch64')} 17:51:48 so, that's good 17:51:53 In RC4, not RC5: 17:51:53 set() 17:51:56 (i.e. nothing) 17:52:01 cool. 17:52:03 so, RC5 has a couple images that got missed from RC4 17:52:22 mattdm: it worked on 1.5 17:52:36 if we had no RC-1.5 i could see us waiving this one too, but since we have it, I'd say let's ship it, call this +1 blocker or +1 FE or whatever 17:52:46 * nirik nods. 17:52:49 ok 17:52:50 yes that 17:52:52 wfm 17:52:57 +1 17:53:35 mboddu: thanks also for your help getting these RCs built over the weekend and holiday 17:53:51 yep, thanks mboddu 17:53:53 mboddu++ 17:53:53 adamw: Karma for mohanboddu changed to 18 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:53:54 mboddu++ 17:53:56 nb: Karma for mohanboddu changed to 19 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:54:22 mattdm, adamw, nb : no problem, everyone worked hard over the weekend and holidays 17:54:36 so, we've voted to +1 this and ship 1.5 (provided the rest of the blockers are good)? 17:54:45 i believe so 17:54:52 yes 17:54:52 * kparal nods 17:54:58 I think so 17:55:01 ack 17:55:42 yep 17:55:51 yes 17:55:59 and all of the rest of the blockers are *fine* 17:56:01 :) 17:56:37 the juiciest one is still waiting 17:56:49 there's always one more... 17:56:52 proposed #agreed - RHBZ#1467599 - AcceptedBlocker - This bug is a clear violation of the Default Application Functionality criterion. Luckily, this is fixed in the 1.5 RC. Thanks for the quick work. 17:57:00 ack 17:57:01 ack 17:57:14 luckily == adamw did work so 17:57:21 #agreed - RHBZ#1467599 - AcceptedBlocker - This bug is a clear violation of the Default Application Functionality criterion. Luckily, this is fixed in the 1.5 RC. Thanks for the quick work. 17:57:25 adamw++ 17:57:34 sure, ack 17:57:34 last one: 17:57:35 #topic (1370222) session/apps fail to start if hostname changes during boot due to network (infamous xauth issue) 17:57:38 #link https://bugzilla.redhat.com/show_bug.cgi?id=1370222 17:57:41 #info Proposed Blocker, sddm, NEW 17:57:47 our old friend. 17:57:50 you want to read comment 58 and below 17:58:23 i have definitely seen VMs picking up 'old' hostnames like this in some tests i've run 17:58:33 i don't know the ins and outs of when it happens and when it started though 17:58:53 with F26, I'm quite positive 17:59:00 So, the basic summary is that this a long-standing bug which got worse rather than better? 17:59:24 this was originally discovered by jsedlak, because I never actually rebooted an existing KDE VM before. until today when working on KDE testcases 17:59:36 mattdm: yes 17:59:51 we continue to tweak it every time, and it comes back with force 18:00:09 maybe we should finally fix the root cause some day ;) 18:00:15 if you hit this, the 'workaround' is to boot to runlevel 3 and change the hostname? run an xhost command? or what? 18:00:29 hans seems to say it should be pretty simple if someone just pulls their finger out and does it... 18:00:34 adamw: switch to tty2 and set hostname using hostnamectl (or edit /etc/hostname I guess) 18:00:43 kparal: host is f26 (so you get the libvirt with new dhcp behavior?) not on f25 host? 18:00:57 nirik: it works with f25 host 18:01:01 nirik: correct, f26 host 18:01:18 I haven't tested f25 host, but jreznik says it works for him 18:01:30 * nirik nods. 18:01:53 so basically this is a conditional violation of the 'installed system must boot' criterion in the case of booting a KDE install on an F26 libvirt NAT host? 18:02:10 the installed system boots... once 18:02:10 * mattdm did most kde testing on f25 host. :( 18:02:14 but correct 18:02:15 (at least that, and perhaps any other DHCP server that works the same way, I guess) 18:02:41 adamw: that's my worry, I have no idea how often the dhcp servers have this functionality 18:02:43 installed system boots twice but just not all the way up to the desktop login :-/ 18:03:05 mattdm: you see a black screen, but tty switch works 18:03:35 booted! :) 18:03:36 it's still a race, so with a very fast or very slow network, you might not see this 18:03:56 but for me, it happens always. also jsedlak claimed it happened to him very often or all the time 18:04:00 I don't remember exactly 18:04:45 yay race 18:05:06 this one at least seems decent enough to manifest frequently :) 18:05:45 in VM setup, it seems almost guaranteed to hit it, virtual network is fast 18:06:11 btw. Martin is on yacht in Croatia 18:06:19 presumably 'set a hostname during install' avoids it too? 18:06:32 adamw: yes, if you set a custom hostname, that should fix it 18:06:41 but by default, it's localhost.localdomain in anaconda 18:06:49 the new installer design really invites users to not do that 18:06:56 at least once yuo're used to it 18:06:57 unless you get a network hostname from dhcp, anaconda respects that I think 18:07:05 mattdm: yeah, it's kinda hiddenb. 18:07:11 * kparal nods 18:07:33 so i'm really kinda on the fence about this one 18:07:41 so I suppose we could say this doesn't affect too many people, but it's really hard to say. 18:07:45 * nirik is too 18:07:47 I don't think we have a good idea how to fix this, except for properly fixing sddm, which sounds simple according to Hans, but doesn't have to be that much 18:07:48 it's pretty bad, yeah...i'm not quite sure it's worth blocking on 18:07:51 tell me the side of the fence that lets us ship :) 18:08:07 wow, tell us what you really think, mattdm 18:08:08 well, we could fix f26 libvirt to not do what it's doing? 18:08:25 adamw: :) 18:08:25 yeah, we do have the potential to change libvirt, though i suspect they wouldn't be fans of that 18:08:29 adamw is a known libvirt hacker 18:08:29 lol 18:08:34 probibly not. 18:08:43 kparal: shhhh, i'm pretty sure it's illegal in 30 states 18:08:51 kparal: well, don't expect proper sddm fix in next ten days as I said, Martin is on yacht... 18:09:02 ah, that Martin 18:09:12 we could maybe 'special case' the offending hostnames? though we all know how much people love magic special cases in their code 18:09:18 I guess given that this has been broken for 8 months and that we are late and it might not affect too many people, I can be -1 blocker +1 FE +1 f27 alpha? blocker? 18:09:21 the missing fix is the main reason I'd consider -1 here 18:09:26 nirik: the libvirt complication is new in f26 18:09:29 of course with F27 +1 18:09:31 that's why it was reproposed 18:09:34 I know. 18:09:46 it's more broken now... 18:09:52 so it's been broken under f26 all along but no one knew because f26 didn't exist :) 18:10:04 heh 18:10:14 well, it probibly brok this way when libvirt added/changed the dhcp behavior. 18:11:15 proposed #agreed - RHBZ#1370222 - RejectedBlocker - As this bug has a long history and there's no fix available, as well as it being unclear how many people this will affect, we're rejecting it as a blocker for F26. Accepted as a blocker for F27. 18:11:20 how's that sound? 18:11:24 patch 18:11:31 go for it 18:12:14 in 3 months, when everybody has F26, everyone who installs KDE into a VM will be affected. so the number of people will grow 18:12:31 kparal: hopefully we'll have a fix by then 18:12:47 mattdm: but you'll not be able to affect those Live installs 18:12:51 and second reboot breaks 18:13:00 that's before you install updates, very probably 18:13:01 kparal: we may talk to libvirt guys 18:13:09 kparal: unless we make a change on the host side 18:13:13 yeah 18:13:30 still, no magic solution here, so I kinda agree with the proposal 18:13:37 * mattdm is not super happy about installed hosts ending up with "localhost-live" as a hostname anyway. confusing. 18:13:43 * nirik waits for adamw's patch 18:13:47 we'll properly document it in common bugs, of course 18:13:48 ack 18:14:06 still patching 18:14:15 mattdm: they don't get that hostname. it's just retrieved from the network, static one is still localhost.localdomain 18:14:27 but yeah it's confusing that it shows up in console 18:14:44 and that affects gnome as well 18:15:01 proposed #agreed #1370222 - AcceptedBlocker (F27 Alpha) - This is a conditional violation of 'installed system must boot to a desktop' criterion, on subsequent boots after KDE install, on libvirt 3.2+ VMs using libvirt NAT (and possibly other unknown DHCP servers). Some workarounds are available. As the libvirt complication was discovered late and a fix will likely not be forthcoming soon, we agreed to make this a Fedora 27 Alpha blocker (see 18:15:01 #1468239 discussion of time vs. quality). 18:15:24 ack 18:15:26 ack 18:15:27 I think it's kinda silly from systemd to not respect localhost if it is set in /etc/hostname. but I see the other way as well 18:15:45 proposed #agreed #1370222 - AcceptedBlocker (F27 Alpha) - Conditional violation of 'system must boot to a desktop' criterion, on subsequent boots after KDE install, on libvirt 3.2+ VMs using libvirt NAT (and possibly other unknown DHCP servers). Some workarounds are available. As the libvirt complication was discovered late and a fix will likely not be forthcoming soon, we agreed to make this a Fedora 27 Alpha blocker (see #1468239 discussion of 18:15:45 time vs. quality). 18:15:48 siiiiigh 18:15:50 ack 18:15:52 oh IRC and your character limit 18:16:02 bleeding edge technology 18:16:11 ack 18:16:28 proposed #agreed #1370222 - AcceptedBlocker (F27 Alpha) - Conditional violation of 'system must boot to a desktop' criterion, on boots after KDE install, on libvirt 3.2+ VMs using libvirt NAT (and possibly other unknown DHCP servers). Some workarounds are available. As libvirt complication was discovered late and fix will likely not appear soon, we agreed to make this a Fedora 27 Alpha blocker (see #1468239 discussion of time vs. quality). 18:16:29 there! 18:16:36 ack^2 18:16:42 ackack? 18:16:43 still ack 18:16:46 adamw: no alpha for f27 18:16:51 kparal: don't worry, I updated to android wear 2 - we have a lot to learn :D 18:16:56 mboddu: good point :D 18:17:18 adamw: so it should be f27 beta 18:17:20 ack 18:17:30 ok, will adjust 18:17:38 supposing it all works so we don't have an alpha 18:17:39 pre-ack adjusted version :) 18:17:42 proposed #agreed #1370222 - AcceptedBlocker (F27 Beta) - Conditional violation of 'system must boot to a desktop' criterion, on boots after KDE install, on libvirt 3.2+ VMs using libvirt NAT (and possibly other unknown DHCP servers). Some workarounds are available. As libvirt complication was discovered late and fix will likely not appear soon, we agreed to make this a Fedora 27 Beta blocker (see #1468239 discussion of time vs. quality). 18:17:44 I'd keep Alpha, we can internally change that later 18:17:48 ok 18:17:50 OH SHUDDUP 18:17:50 :P 18:17:52 ack 18:17:54 ack ack ack ack 18:17:55 no alpha is on the schedule *now* 18:18:11 ack 18:18:47 #agreed #1370222 - AcceptedBlocker (F27 Beta) - Conditional violation of 'system must boot to a desktop' criterion, on boots after KDE install, on libvirt 3.2+ VMs using libvirt NAT (and possibly other unknown DHCP servers). Some workarounds are available. As libvirt complication was discovered late and fix will likely not appear soon, we agreed to make this a Fedora 27 Beta blocker (see #1468239 discussion of time vs. quality). 18:19:15 well, since wee accepted none for F26, and the rest of the blockers are addressed in RC1.[4,5], we 18:19:23 are done with this bit of the meeting methinks 18:19:30 anyone have anything else? 18:19:37 there are still some unverified accepted blockers 18:19:45 4 ON_QA 18:19:49 fwiw KDE people reading this in the future: I'm definitely open to putting a post-GA KDE 26 nightly on the kde spins page sometime in the future 18:20:17 * roshi thought all of those had fixes in the latest RCs 18:20:20 mattdm: there are community respins too 18:20:23 ok, will go through those 18:20:30 #topic (1466887) Fedora 26 Final build of fedora-release-notes needed 18:20:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=1466887 18:20:31 #info Accepted Blocker, fedora-release-notes, ON_QA 18:20:40 i think we're pretty good with all the ON_QAs. 18:20:53 things seemed fixed for me 18:20:58 rpiv3 booted fine 18:21:05 but let's go through 'em for safety. 18:21:27 makes sense 18:21:40 https://dl.fedoraproject.org/pub/alt/stage/26_RC-1.5/Everything/x86_64/os/Packages/f/fedora-release-notes-26.02-2.fc26.noarch.rpm 18:21:44 ->VERIFIED 18:21:52 sweet 18:22:09 #topic (1387733) Blank screen after boot on Raspberry Pi 18:22:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=1387733 18:22:09 #info Accepted Blocker, kernel, ON_QA 18:22:21 this is reported working in-bug, right? 18:22:32 * mboddu is interested in this bug 18:22:43 looks like 18:22:46 rpi3 soas works here 18:23:16 just set it VERIFIED 18:23:33 kk 18:23:41 #topic (1466914) Fedora 26 Final build of spin-kickstarts needed 18:23:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1466914 18:23:41 #info Accepted Blocker, spin-kickstarts, ON_QA 18:24:08 hmm, let me confirm this one 18:24:32 https://dl.fedoraproject.org/pub/alt/stage/26_RC-1.5/Everything/x86_64/os/Packages/s/spin-kickstarts-0.26.1-1.fc26.noarch.rpm 18:24:35 let's check the contents 18:24:42 * nirik made a package, submitted it. Hope it's right. ;) 18:26:05 yup, looks good. 18:26:11 sweet 18:26:37 #info This package has been updated and the fix is VERIFIED. 18:26:38 #topic (1404285) TrackerDirectConnection crashes from sqlite3DbMallocRawNN 18:26:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1404285 18:26:44 #info Accepted Blocker, tracker, ON_QA 18:28:15 well, we don't have direct confirmation either way with this one, but did we have a clean reproducer? 18:28:16 * adamw checks 18:28:45 * adamw tries cole's reproducer 18:30:28 welp, i tried cole's reproducer and it didn't crash 18:30:37 i haven't confirmed that it *does* crash with an older image, but... 18:31:52 anyone here had this reproduced before? 18:32:32 * roshi hasn't tried 18:32:49 well, if it doesn't crash 18:33:21 btw. could you please cover QA part for me - #topic Test Matrices coverage - I need 10 minutes afk 18:33:47 brb 18:33:58 sure 18:34:00 * roshi waits to adamw 18:34:08 for adamw, rather 18:34:09 i was waiting to see if anyone else had more data, but... 18:34:16 yeah 18:34:31 #info We did our best to verify this one, it seems to be fixed 18:34:42 that was the last one, right? 18:34:46 that's it for blocker review bits 18:34:48 yep 18:36:49 so 18:36:54 #topic Test Matrices coverage 18:36:58 let's see! 18:37:13 the matrix is all around us! 18:39:20 as always, https://www.happyassassin.net/testcase_stats/26 is helpful here 18:39:41 #info RC-1.5 and RC-1.4 are almost identical, only qemu differs between them, so let's consider RC-1.4 results acceptable 18:39:46 looks like decent coverage, overall 18:39:48 +1 18:40:23 we're missing Xen virt, again 18:40:37 i can't recall if we talked about that last time, but if it keeps not getting tested we need to drop it from the criteria 18:40:49 the deal was that we'd have it in the criteria if Oracle tested it, they're not testing it 18:40:58 didn't we drop that last time? feels like we did, for this reason 18:41:26 we might have decided to and then forgotten about it 18:41:35 anyone want to dig up the f25 go/no-go meeting logs while i look through the criteria? 18:41:36 +1 to drop Xen 18:41:49 our old friend install_to_SAS as well, ho ho 18:41:54 adamw: we can decide *again* :) 18:41:56 no-one tested FCoE? boo 18:42:33 huh, FCoE was broken in 25 and we shipped it anyway, apparently 18:42:37 https://bugzilla.redhat.com/show_bug.cgi?id=1370412 18:42:47 so...what the hell is wrong with us 18:42:53 QA is hard, let's go shopping 18:45:16 well, clicking "Add FCoE SAN..." works in F26, so that's an improvement! 18:45:25 (i did once try to do automated FCoE testing but it was hard so i gave up) 18:46:15 there's a few things that were last tested in RC-1.3 but they all look like stuff that shouldn't have changed in RC-1.4, i think it's ok 18:47:47 so...other than that, coverage looks pretty good 18:48:50 #info missing tests: install_to_SAS, Boot_Methods_Xen_Para_Virt , install_to_FCoE_target 18:49:41 is the xen one handled by aws? or thats different? 18:49:45 proposed #agreed Xen_Para_Virt test should be demoted to Optional and criteria adjusted as Oracle does not seem to be providing testing any more 18:49:51 nirik: bit different, i think 18:50:03 +1 18:50:06 it's loong time ago I was running my last go/no-go and there are still the same usual suspects not tested :) 18:50:16 +1 18:50:19 ack 18:50:43 ack, I mean 18:50:50 ack 18:50:52 jreznik: yeah, we really should do something :/ i proposed QA buying some SAS hardware after f25 cycle, but that discussion kinda died 18:50:58 #agreed Xen_Para_Virt test should be demoted to Optional and criteria adjusted as Oracle does not seem to be providing testing any more 18:51:02 grrr 18:51:07 #agreed Xen_Para_Virt test should be demoted to Optional and criteria adjusted as Oracle does not seem to be providing testing any more 18:51:15 AWS still uses xen but it's some weird custom thing 18:51:19 that might not be generalizable 18:52:03 proposed #agreed SAS and FCoE testing have been missed due to hardware availability, this has happened before and we consider it unfortunate but acceptable; note it appears FCoE was broken in F25 and appears to be at least less broken in F26 18:52:32 ack 18:53:14 ack 18:53:22 ack 18:53:37 ack 18:53:48 (we have 7 minutes till readiness meeting :D) 18:54:11 6 min now ;) 18:54:12 #agreed SAS and FCoE testing have been missed due to hardware availability, this has happened before and we consider it unfortunate but acceptable; note it appears FCoE was broken in F25 and appears to be at least less broken in F26 18:54:32 #info with the above notes / provisos, test coverage is substantially complete 18:54:45 jreznik: back to you? 18:54:46 awesome! thanks! 18:54:49 adamw: sure 18:55:05 #topic Go/No-Go decision 18:55:29 welp, not super happy with all the fudging, but with the above decisions QA's vote should be GO per our policy 18:55:46 as it was discussed in the past two hours, we don't have any unresolved blocker and QE coverage is complete... so... SO... 18:55:52 thanks adamw 18:56:06 nirik for eng and mboddu for RCM? are you Go? 18:56:08 yeah, lots of contortions... but go it is in the end. 18:57:21 * roshi concurs with adamw 18:57:40 oh 18:57:42 that is, GO to ship RC-1.5 18:58:01 proposal #agreed Fedora 26 Final status is go (RC-1.5) by Release Engineering, QA and Development 18:58:02 yeah 18:58:07 Go from releng 18:58:09 ack 18:58:26 nirik: one more ack please! 18:58:29 ack 18:58:29 ack 18:58:34 ack 18:58:40 #agreed Fedora 26 Final status is go (RC-1.5) by Release Engineering, QA and Development 18:58:52 \o/ 18:58:56 perfect timing, two minutes left! 18:59:01 ! 18:59:10 * roshi preps his drinks 18:59:15 it's nice to steal this moment from jkurik :D 18:59:19 haha 18:59:20 one for the Go, and one for the kludging 18:59:24 Where can I download the iso before publishing? 18:59:35 two for the money, three for the fudging 18:59:37 I need to do marketing work 18:59:39 I hope we can set up future releases to be in better situations with less kludging 18:59:48 me too 18:59:51 let's hope so 18:59:54 x3mboy: https://dl.fedoraproject.org/pub/alt/stage/26_RC-1.5/ 19:00:05 Thanks mattdm! 19:00:14 CI and automation will save us all! 19:00:15 It looks like it will be a hard weekend 19:00:21 * mattdm has some ideas; we should have a retrospective. 19:00:25 and next time I'll try to be more involved than this cycle... I was covering an additional product for my day job and baby girl, too much :) 19:00:25 But still happy that we have a candidate 19:00:32 jreznik++ 19:00:32 mattdm: Karma for jreznik changed to 1 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:00:46 heh last chance for cookies! 19:00:46 #info mattdm had an idea - let's do retrospective! 19:01:03 jreznik++ 19:01:14 ok, thanks everyone! enjoy the new release 19:01:17 * mattdm 's idea was actually from mmcgrath but it's a good idea 19:01:37 * jreznik will announce it right after the readiness meeting, attendance might be lower, so soon 19:01:53 jreznik: ha. let's maybe *schedule* it 19:02:09 #endmeeting