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