17:00:06 <bcotton_> #startmeeting F35 Final Go/No-Go meeting
17:00:06 <zodbot> Meeting started Thu Oct 21 17:00:06 2021 UTC.
17:00:06 <zodbot> This meeting is logged and archived in a public location.
17:00:06 <zodbot> The chair is bcotton_. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:06 <zodbot> The meeting name has been set to 'f35_final_go/no-go_meeting'
17:00:17 <bcotton_> #meetingname F35-Final-Go_No_Go-meeting
17:00:17 <zodbot> The meeting name has been set to 'f35-final-go_no_go-meeting'
17:00:22 <bcotton_> #topic Roll Call
17:00:36 * bittin is partly here watching an AlmaLinux stream at the same time
17:00:44 <nirik> morning
17:00:46 <adamw> ahoy to the oy
17:00:51 <coremodule> .hello2
17:00:52 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:01:32 <pwhalen> .hello2
17:01:33 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
17:01:52 <leothecat> hi!
17:01:58 <lruzicka2> .hello lruzicka
17:01:59 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:02:03 <geraldosimiao> .hello geraldosimiao
17:02:03 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
17:02:03 <adamw> .hello adamwill
17:02:06 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:02:18 <leothecat> just watching ;)
17:02:25 * lruzicka2 only has like 60 minutes max, so we better hurry :D
17:02:29 <bcotton_> well the good news is that the bridge seems a little better this morning
17:03:02 * nirik should feed cats, but don't want to miss exciting go/no-go action
17:03:12 <bcotton_> i'm gonna wait a liiiiiiiiiiiitle bit longer so that nirik doesn't have to wear both the fesco and releng hats, but i think the answer will end up being pretty clear
17:03:25 <adamw> hmm, you do? i have no idea
17:03:35 <nirik> every day is a adventure!
17:03:48 <nirik> we are pretty good at waiving or voting down things....
17:03:50 <adamw> for the record, i didn't close any votes even where we had +3/-3 because i figured at this point it'd be best to consider them altogether at the meeting
17:03:56 <bcotton_> adamw++
17:04:13 <bcotton_> okay, let's go ahead and start the process because wow
17:04:28 * sumantro is here
17:04:32 <bcotton_> #topic Purpose of this meeting
17:04:34 <bcotton_> #info Purpose of this meeting is to check whether or not F35 Final is ready for shipment, according to the release criteria.
17:04:35 <bcotton_> #info This is determined in a few ways:
17:04:37 <bcotton_> #info 1. No remaining blocker bugs
17:04:38 <bcotton_> #info 2. Release candidate compose is available
17:04:40 <bcotton_> #info 3. Test matrices for Final are fully completed
17:04:44 <bcotton_> #topic Current status - blockers
17:04:46 <bcotton_> #link https://qa.fedoraproject.org/blockerbugs/milestone/35/final/buglist
17:04:47 <bcotton_> dp o
17:04:57 <bcotton_> finger off-by-one error
17:05:12 <adamw> removes one finger
17:05:22 <bcotton_> so i'm going to do this in a slightly different order because there are a lot of proposed blockers
17:05:57 <bcotton_> i'll start with the one that seems to me like the most likely to derail us and if we agree it will derail us, we won't go through the rest because that's what the blocker review meeting is for
17:06:15 <bcotton_> #info 7 Proposed Blockers
17:06:17 <bcotton_> #info 2 Accepted Blockers
17:06:18 <bcotton_> #info 0 Accepted 0-day Blockers
17:06:20 <bcotton_> #info 0 Accepted Previous Release Blockers
17:06:32 <bcotton_> #topic (2016310) The KDE LiveCD 35 RC does not boot in basic graphics mode.
17:06:33 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2016310
17:06:35 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/562
17:06:36 <bcotton_> #info Proposed Blocker, LiveCD - KDE, NEW
17:06:38 <bcotton_> #info Ticket vote: FinalBlocker (+4,0,-0) (+kparal, +sumantrom, +lruzicka, +frantisekz)
17:06:58 <adamw> i'm definitely +1 blocker on this, don't see what else you can vote
17:07:11 <adamw> note we accepted an identical bug as blocker for f31 final - https://bugzilla.redhat.com/show_bug.cgi?id=1728240#
17:07:20 <bcotton_> +1 blocker from me too
17:07:23 <pwhalen> +1 blocker :(
17:07:36 <bittin> +1 blocker
17:07:42 <nirik> +1 blocker
17:07:43 <coremodule> +1 blocker
17:07:44 <nirik> sadly
17:08:04 <nirik> I guess you could argue bios instead of efi is more fringe...
17:08:18 <adamw> i think we can argue about waiving it
17:08:36 <nirik> under the 'sorry, too close to go/nogo'
17:08:37 <nirik> ?
17:08:37 <adamw> maybe we should do all the blocker votes, then we can decide if we want to consider waiving all accepted blockers
17:09:13 <sumantro> adamw, I agree
17:09:13 <adamw> i will answer that question when we decide to discuss waiving :D
17:09:34 <bcotton_> adamw: normally i'd agree, but with as many proposed blockers as we have, i want to respect people's time
17:09:38 <bcotton_> but for now
17:10:03 <adamw> well, i feel like we can make a better decision on waiving when we know what accepetd blockers we're dealing with...
17:10:59 <bcotton_> proposed #agreed 2016310 - AcceptedBlocker (Final) - This is a clear violation of the "basic graphics mode" criterion
17:11:16 <lruzicka2> ack
17:11:23 <adamw> ack
17:11:25 <bittin> ack
17:11:27 <coremodule> ack
17:11:38 <geraldosimiao> ack
17:11:41 <nirik> ack
17:11:50 <sumantro> ack
17:12:01 <bcotton_> #agreed 2016310 - AcceptedBlocker (Final) - This is a clear violation of the "basic graphics mode" criterion
17:12:51 <bcotton_> okay, so personally, i have a hard time imagining that i'd vote to waive this so i'm happy to shortcut at this point. but if the majority wants to go through the whole list, we can do that
17:14:06 <adamw> i can see the argument for waiving, at least
17:14:08 <bcotton_> how about this: +1 go through the whole list, -1 make a waive decision on this bug right now
17:14:14 <adamw> we found it today (i've no idea why it wasn't tested earlier, sorry about that)
17:14:49 <nirik> -1 I guess, to save time...
17:15:05 <adamw> and bios vs. uefi is kinda significant, as the main 'plausible' use case for basic graphics is on shiny new graphics cards that we don't have driver support for yet. these days, that's highly likely to be on a UEFI-capable system.
17:15:08 <bittin> +1
17:15:11 <adamw> but i can see the other side too, i guess.
17:16:09 <bcotton_> anyone have an opinion on how we proceed?
17:16:49 * pwhalen is torn
17:16:50 <lruzicka2> I am in time pressure, so for me -1 makes sense, but if I weren't I'd go +1 :)
17:16:59 <nirik> how many more proposed blockers are there?
17:17:06 <bittin> 6
17:17:07 <sumantro> -1 on making a decision right now and +1 on going through the list, so we know what "net" blockers we have and then decide if we are at all going to waive
17:17:31 <bcotton_> six more proposed blockers, but several of them have enough votes ot make a quick decision
17:17:37 <bcotton_> okay, so let's go through the list then
17:17:42 <adamw> right, most of them should be quick
17:17:47 <geraldosimiao> sumantro: ack
17:17:51 <nirik> lightning round!
17:18:32 <lruzicka2> let's do it
17:18:35 <bcotton_> #topic (2015809) app can't be installed&removed or removed&installed, without Discover restart
17:18:37 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2015809
17:18:38 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/560
17:18:40 <bcotton_> #info Proposed Blocker, plasma-discover, NEW
17:18:41 <bcotton_> #info Ticket vote: FinalBlocker (+2,0,-6) (+kparal, +lruzicka, -frantisekz, -geraldosimiao, -adamwill, -bcotton, -kevin, -scorreia)
17:18:50 * nirik already voted in ticket
17:18:53 <sumantro> -1
17:19:04 <bittin> -1
17:19:29 <coremodule> -1 blocker
17:19:35 <adamw> still -1 (from ticket), +1 FE
17:19:37 <lruzicka2> seems like this one's out
17:19:43 <adamw> (since there's a chance we slip, it'd be nice to fix this if we could)
17:19:56 <lruzicka2> +1 fe
17:20:40 <nirik> yeah, +1 FE for sure.
17:20:59 <geraldosimiao> ok, +1 FE
17:21:20 <bcotton_> proposed #agreed 2015809 - RejectedBlocker(Final) AcceptedFreezeException(Final) - It is functional enough to ship and fix in an update, but we'd like to have it in the release if a fix is available and we slip
17:21:20 <pwhalen> -1 B, +1 FE
17:21:28 <pwhalen> ack
17:21:36 <bittin> ack
17:21:48 <Southern_Gentlem> ack
17:21:56 <geraldosimiao> ack
17:21:58 <coremodule> ack
17:22:03 <adamw> ack
17:22:07 <sumantro> ack
17:22:08 <nirik> ack
17:22:54 <bcotton_> #agreed 2015809 - RejectedBlocker(Final) AcceptedFreezeException(Final) - It is functional enough to ship and fix in an update, but we'd like to have it in the release if a fix is available and we slip
17:23:06 <bittin> ack
17:23:21 <geraldosimiao> ack
17:23:23 <bcotton_> #topic (2015490) It is possible to go through the initial setup without creating a root and without adding a user to the wheel group
17:23:24 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2015490
17:23:26 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/555
17:23:28 <bcotton_> #info Proposed Blocker, initial-setup, NEW
17:23:29 <bcotton_> #info Ticket vote: FinalBlocker (+1,0,-7) (+pwhalen, -catanzaro, -lruzicka, -adamwill, -geraldosimiao, -bcotton, -kevin, -sumantrom)
17:23:31 <bcotton_> #info Ticket vote: FinalFreezeException (+1,0,-0) (+adamwill)
17:23:53 <bittin> +1 blocker
17:23:54 <adamw> i think we can count pbrobinson as +1 on this too, though he didn't formally vote
17:23:56 * nirik still -1 Blocker, +1 FE
17:24:03 <adamw> it is a significant issue for arm deployments, we shouldn't downplay that
17:24:05 <pwhalen> heh, I was clearly outvoted on this, but more convinced that this may have been the case for some time
17:24:11 <adamw> just because you're not used to seeing it on x86_64 installs :D
17:24:27 <adamw> pwhalen: did we establish whether it's new or not?
17:24:47 <pwhalen> adamw: not yet
17:25:53 <adamw> to me this comes down to a bit of an intangible - how likely people are to only create a non-admin user, if we don't block them
17:26:04 <adamw> do most people enable the root account? do most people set the user account as an admin without any nudging? it seems hard to say
17:26:05 <nirik> yeah.
17:26:08 <bcotton_> By my count, we're at +3,0,-7. i feel like that's a big enough margin to make a decision but with an "i told you so" card reserved for pwhalen and pbrobinson
17:26:18 <adamw> it is at least relatively easy to just re-do the deployment if you mess it up
17:26:38 <Southern_Gentlem> -1b +1fe
17:26:44 <lruzicka2> We still have the Common Bugs where we can mention this and people reading it might avoid this.
17:26:52 <adamw> bcotton_: i'm counted as a -1 but i'm pretty weak on that
17:27:33 <bcotton_> i'm like a -0.75
17:27:47 <adamw> -0.46
17:27:53 <geraldosimiao> +1 FE
17:27:54 <Southern_Gentlem> its during the install so they can redo it
17:28:02 <bcotton_> the "reinstall if you make bad decisions" argument is compelling, but i'm worried about a case where someone goes a week or two before they realize they made bad choices
17:28:11 <geraldosimiao> I'm still -1 FB
17:28:17 <adamw> bcotton_: it does make us look kinda bad too, tbh
17:28:34 <Southern_Gentlem> bcotton_, put it in the commonbugs
17:28:36 <nirik> but we might have looked this bad for a while, just didn't notice. ;)
17:28:52 <adamw> heh.
17:29:09 <bcotton_> yeah. it's one thing to let people make inadvisable choices, but this is kind of a big one
17:29:14 <adamw> can we check quickly if it's true for f34? i still don't have an arm setup handy, been fighting other bugs all week
17:29:21 <adamw> if f34 is the same i'd be happier with my -1
17:29:21 <pwhalen> I am now
17:29:26 <adamw> thanks
17:29:30 <bcotton_> pwhalen++
17:29:30 <zodbot> bcotton_: Karma for pwhalen changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:29:41 * nirik has to step away for a few, back in a few.
17:29:51 <bcotton_> pwhalen: should we wait a moment or come back to this?
17:29:53 <adamw> maybe we can do the next bug while we wait?
17:30:05 <pwhalen> come back, it;ll take a few
17:30:09 <bcotton_> ack
17:30:16 <bcotton_> #info pwhalen is testing. we will come back to this
17:30:39 <bcotton_> #topic (2010740) after enabling third-party repos, the included apps can't be found (except Chrome)
17:30:40 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2010740
17:30:42 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/500
17:30:43 <bcotton_> #info Proposed Blocker, gnome-software, ASSIGNED
17:30:45 <bcotton_> #info Ticket vote: FinalBlocker (+1,0,-4) (+kparal, -catanzaro, -frantisekz, -lruzicka, -sumantrom)
17:30:46 <geraldosimiao> ack
17:31:29 <bittin> Blocker -1 FE +1
17:32:14 <adamw> so what this is covering ATM is that now, sometimes, if you enable third-party repos in gnome-initial-setup, it works, but GNOME Software doesn't show packages from them
17:32:29 <adamw> for some reason, kparal can reproduce this nearly every time. for everyone else who's tried, it's less common.
17:32:51 <bcotton_> (the reason is kparal ;-) )
17:33:00 <adamw> i've been testing it in the background all morning; my score so far is out of 6 tries, it worked fine on 4 of them, on 2 of them i could see Chrome but not the NVIDIA driver for some reason.
17:33:18 <bcotton_> so is it that post-install Software doesn't see the packages from the repos added during g-i-s?
17:33:23 <geraldosimiao> bcotton_: 🤣
17:33:28 <adamw> yeah. sometimes.
17:33:49 <bittin> https://pagure.io/fedora-qa/blocker-review/issue/500#comment-758656
17:33:49 <adamw> if you do a 'pkcon refresh' they start showing up. or if you wait a day or two they will start showing up too - but obviously most people aren't gonna see that, if they hit this bug.
17:34:05 <adamw> er, i mean, aren't gonna be okay about just waiting a day.
17:34:38 <bittin> adamw, maybe write that people can run pkcon refresh in known problems?
17:34:56 <adamw> of course we'd do that
17:35:00 <bcotton_> The fact that we can `pkcon refresh` our way out of it makes me feel better about it. although it's still going to be embarassing if a reviewer hit is :/
17:35:03 <adamw> but there's gotta be a limit to what we can cover in common bugs :D
17:35:05 <bcotton_> hits it, too
17:35:30 <adamw> "Fedora 35 is known to eat all babies within a 100m radius. To work around this issue, please yell a loud warning to move all babies five minutes before you boot it"
17:36:52 <bcotton_> so i think i'm a weak -1 on blocking on this
17:36:56 <adamw> so for me this one is pretty squishy too (i thought we were gonna do an easier one next :>)
17:37:15 <bcotton_> which puts us at about +1,0,-6
17:37:16 <kparal> adamw: adamw: Chrome doesn't count, we ship Chrome's metadata ourselves
17:37:17 <adamw> 7th try, no nvidia again
17:37:28 <adamw> so i'm batting 100 on chrome but like 600 on nvidia
17:37:28 <kparal> only steam and nvidia counts
17:37:41 <adamw> oh, i see
17:37:46 <adamw> so yeah, i'm hitting this nearly half the time then. hmm
17:37:55 <adamw> 3 out of 7 so far.
17:38:25 <bcotton_> that's definitely moving me toward the +1 camp. although i'm not sure i'm there yet
17:38:42 <adamw> try #8 coming up!
17:39:12 <kparal> a few hours ago my success rate was 10%
17:39:20 <kparal> before that, 50%
17:39:29 <kparal> for lruzicka and frantisekz, 100%
17:39:34 <kparal> so it's all over the place
17:39:39 <Southern_Gentlem> ok so if they hit this bug can they go into software and enable those repos
17:39:43 <lruzicka2> yeah, but I could only do like 5 runs.
17:39:53 <sumantro> Southern_Gentlem, yes
17:40:00 <lruzicka2> sumantro, Southern_Gentlem: no
17:40:03 <kparal> no, those repos are enabled
17:40:04 <adamw> #8, bad again
17:40:12 <kparal> they must force refresh the repos
17:40:14 <lruzicka2> the repos are enables, but they do not provide any packages
17:40:21 <lruzicka2> until they refresh
17:40:27 <bcotton_> if the user turns the repo off and then back on again, does that force a refresh?
17:40:36 <kparal> gnome-software doesn't see them, to be more exact, until you refresh
17:40:42 <kparal> dnf and pkcon works fine
17:40:47 <bcotton_> iow does it only affect repos added at initial setup?
17:40:55 <adamw> even if it does, how's that ok? we already decided to block on 'turning them on in g-i-s doesn't work' before
17:40:59 <kparal> bcotton_: it should, yes
17:41:05 <kparal> but it's easier for check for updates in gnome-software in the Updates tab
17:41:08 <adamw> hard to see how 'it technically works but you have to turn them off and on again first' is better
17:41:16 <Southern_Gentlem> take them out of gis
17:41:33 <Southern_Gentlem> +1B
17:41:36 <bcotton_> adamw: i'm not sure it's better. i just want to make sure i understand the scope of the issue
17:41:42 <adamw> ok.
17:41:57 <bcotton_> okay, i'm changing my vote to +1 blocker
17:42:31 <bcotton_> which makes it +3,0,-5 i think
17:42:48 * nirik gets back, reads up
17:42:55 <bittin> can the gnome guys update gis to run a small script that runs pkcon update or something?
17:43:11 <kparal> sure. unless it hits issues with selinux again...
17:43:15 <bcotton_> bittin: not if we ship it as-is :-)
17:43:24 <bittin> true
17:43:33 * bittin changes vote to +1 blocker
17:43:43 <lruzicka2> when you switch a repo in Software, it does refresh, unless the following means something else:
17:43:45 <adamw> yeah, i think i'm +1 based on mine and kparal's results
17:43:47 <pwhalen> +1 blocker here as well
17:44:09 <bcotton_> okay so we're at +6/-4
17:44:50 <adamw> i would think mcatanzaro could well change his vote back too
17:45:09 <bcotton_> or +5/-4? hard to keep track since people are voting in the ticket and in the meeting
17:45:09 <nirik> yeah, this one is tough... sounds like it's more common than first thought as well.
17:45:14 * bcotton_ grabs a bad of paper
17:46:07 <adamw> i'm asking mcatanzaro to check in
17:46:21 <nirik> I guess +1 blocker... since this is a change thats going to be advertised here, so likely lots of people will try this.
17:46:22 <bcotton_> lruzicka2: are you still -1?
17:46:25 <coremodule> +1 blocker here
17:46:56 <geraldosimiao> <adamw> "hard to see how 'it technically..." <- by this excellent argument I vote +1 FB
17:47:01 <adamw> bcotton_: criterion is the 'things in initial setup must work' one, btw
17:47:02 <lruzicka2> bcotton_, I am a DNF user, so it's hard for me to feel the severity of this
17:47:11 <bcotton_> adamw: ack
17:47:14 * kparal goes afk again, sorry
17:47:15 <lruzicka2> bcotton_, but I think I am like 0
17:47:20 <bcotton_> lruzicka2: ack
17:47:33 <sumantro> changing my votes, considering its a new feature and lot more press would try it out. +1 Blocker.
17:47:59 <bcotton_> okay, that puts us at +8/1/-2
17:48:07 <bcotton_> that's a compelling majority
17:48:29 <lruzicka2> 8 Fedora release killers :D:D
17:49:01 <geraldosimiao> lruzicka2: blame kparal
17:49:23 <adamw> that guy
17:49:35 <nirik> actually testing that things work! The audacity!
17:49:37 <lruzicka2> geraldosimiao, I pitty him. It must be a tough thing to live in a hell like this, where no computers work for you :D
17:49:53 <bcotton_> proposed #agreed 2010740 - AcceptedBlocker(Final) - This occurs often enough in testing to violate the final criterion: If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test.
17:49:58 <geraldosimiao> 🤣🤣🤣
17:50:03 <lruzicka2> ack
17:50:05 <geraldosimiao> ack
17:50:07 <bittin> ack
17:50:08 <bcotton_> assuming that's the "initial setup must work" that adamw was referring to
17:50:08 <pwhalen> lruzicka2: heh
17:50:09 <sumantro> ack
17:50:12 <coremodule> ack
17:50:18 <pwhalen> ack
17:50:23 <adamw> ypu it is
17:50:24 <adamw> ack
17:50:32 <bcotton_> #agreed 2010740 - AcceptedBlocker(Final) - This occurs often enough in testing to violate the final criterion: If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test.
17:50:40 <adamw> this is the "basic functionality test" part. this page has one function and it practically doesn't work 40% of the time. :D
17:50:51 <geraldosimiao> ack
17:51:07 <bcotton_> pwhalen are you ready for us or should we do another one?
17:51:09 <nirik> ack
17:51:26 <pwhalen> f34 was the same
17:51:52 <lruzicka2> cool, -1FB, +1FE for me then
17:51:52 <adamw> we just didn't spot it? heh
17:52:01 <adamw> we need to change topic back first
17:52:25 <bcotton_> #topic (2015490) It is possible to go through the initial setup without creating a root and without adding a user to the wheel group
17:52:27 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2015490
17:52:28 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/555
17:52:30 <bcotton_> #info Proposed Blocker, initial-setup, NEW
17:52:31 <bcotton_> #info Ticket vote: FinalBlocker (+1,0,-7) (+pwhalen, -catanzaro, -lruzicka, -adamwill, -geraldosimiao, -bcotton, -kevin, -sumantrom)
17:52:32 <bcotton_> #info Ticket vote: FinalFreezeException (+1,0,-0) (+adamwill)
17:52:42 <bcotton_> #info pwhalen confirms this behavior existed in F34
17:52:59 <adamw> so i'll come down -1 on this one on that basis
17:53:02 <lruzicka2> cool, -1FB, +1FE for me then
17:53:08 <adamw> yeah, +1 FE
17:53:12 <pwhalen> +1FE for sure
17:53:14 <sumantro> -1 FB
17:53:18 <bcotton_> same. i might entertain it as an f36 beta blocker, but that's not for today
17:53:25 <geraldosimiao> +1FE
17:53:33 <nirik> -1FB, +1 FE
17:53:40 <lruzicka2> and I am afraid I need to rush out ... sorry about that and have fun
17:53:54 <pwhalen> have a good weekend lruzicka2
17:54:27 <adamw> yup!
17:54:37 <bcotton_> proposed #agreed 2015490 - RejectedBlocker(Final) AcceptedFreezeException(Final)  CommonBugs - This can be fixed with a reinstall if noticed quickly and is a behavior that existed in previous releases
17:54:47 <adamw> ack
17:54:52 <nirik> ack
17:55:02 <geraldosimiao> ack
17:55:08 <pwhalen> ack
17:55:09 <coremodule> ack
17:55:19 <sumantro> ack
17:55:24 <bcotton_> #agreed 2015490 - RejectedBlocker(Final) AcceptedFreezeException(Final)  CommonBugs - This can be fixed with a reinstall if noticed quickly and is a behavior that existed in previous releases
17:55:55 <bcotton_> #topic (2011928) Fedora 35 aarch64 cloud image based openstack VM hangs
17:55:56 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2011928
17:55:58 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/525
17:55:59 <bcotton_> #info Proposed Blocker, kernel, NEW
17:56:01 <bcotton_> #info Ticket vote: FinalBlocker (+1,0,-0) (+bcotton)
17:56:23 <bcotton_> so i'm not sure i'm still +1 on this. it seems like there's a lot of uncertainty about this one?
17:56:35 <adamw> so this one is also a bit murky, because folks are having all sorts of fun pinning down exactly the trigger
17:57:12 <adamw> thanks a lot to cmurf and pwhalen and dusty for working on this btw
17:57:16 <nirik> yeah, unclear how many instances it would affect... just that vendor? all openstack?
17:57:42 <pwhalen> indeed, I am still very concerned about it. It affects at least one, maybe two types of Enterprise hardware
17:57:53 <adamw> i think so far it seems likely that it's triggered by specific hw, and the cloud vendor we're testing on runs some instances on that hw
17:57:56 <adamw> but we couldn't say for sure
17:58:10 <adamw> it does seem like it happens on f34 too, right?
17:58:12 <pwhalen> nirik: I hit a similar issue testing F34
17:58:28 <nirik> thats when we switched cloud to btrfs right?
17:58:39 <bcotton_> cloud to btrfs is f35
17:58:50 <nirik> ah, so it's unrelated to btrfs... ?
17:58:57 <adamw> if we assume that we're gonna slip now (not waive both the blockers we approved so far), i might actually vote to punt on this again...
17:59:21 <bcotton_> if f34 is affected, i'd say it's not btrfs, yeah
17:59:24 <pwhalen> In f34 I hit it installing to btrfs, the hw was fine when using server edition
17:59:38 <bittin> (no vote)
17:59:55 <pwhalen> F34 bug - https://bugzilla.redhat.com/show_bug.cgi?id=1949334
18:00:42 <nirik> hum, I thought this was cloud media? it's install media instead?
18:00:52 <adamw> pwhalen: ah, so it could still be that the bug is more of a problem on f35 than f34 even if technically present on both?
18:01:04 <bcotton_> pwhalen: what image was that f34 bug using?
18:01:34 <pwhalen> bcotton_: wasnt an image, default installation
18:01:59 <bcotton_> okay, but what variant?
18:02:11 <bcotton_> sorry i wasn't clear
18:02:33 <pwhalen> pxe installation from the Everything repo
18:03:16 * mboddu is here and hope its not too late
18:03:32 <pwhalen> I have only seen it when testing on the Amberwing, until this vexxhost issue
18:04:01 <bcotton_> this bug is vexxing
18:04:02 <nirik> and only on btrfs it seems like.
18:04:20 <pwhalen> Installations mostly fail when using the btrfs default, server repo with xfs as the default is Ok
18:04:24 <nirik> pwhalen: did you enable compression? or just btrfs
18:04:41 <bittin> mboddu, still 3 blockers left to discuss
18:04:44 <adamw> pwhalen: do we have a contact at vexxhost we can ask about their hw?
18:04:45 <pwhalen> just btrfs, its a beaker host
18:04:57 <pwhalen> adamw: no idea about vexxhost
18:05:10 <adamw> bcotton_: do you have any idea?
18:05:18 <geraldosimiao> bcotton_: ;D
18:05:42 <bcotton_> adamw: about a contact? Major Hayden would know, I think. I saw that we're on vexxhost from his tweet
18:06:00 <adamw> ok, let's ask him
18:06:02 <pwhalen> Looking at this bug, I think the vexxhost was a thunderX.. recall seeing it somewhere in the BT
18:06:26 <bcotton_> #action bcotton to Check with Major Hayden if he has a contact at vexxhost who could help us with this
18:06:36 <adamw> would the bt show the real host hardware, though, or whatever the instance is emulating?
18:06:58 <bcotton_> i guess for now let's proceed with the rest and see how we feel for all of the other bugs?
18:07:06 <adamw> yeah, let's do that
18:07:18 <adamw> unless we absolutely need to make a decision on this today, my vote is punt
18:07:24 * nirik nods
18:07:31 <bcotton_> the chair would also entertain a motion to just say "yeah, we have too many blockers, let's just call it a day" :-)
18:07:47 <bcotton_> #info We'll proceed with the remaining blockers and see if we can punt on this one again
18:07:59 <adamw> let's get the others voted on now we're here :D
18:08:04 <mboddu> punt
18:08:11 <bcotton_> #topic (2015491) Install/Remove buttons are cropped, the text is off-screen
18:08:12 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2015491
18:08:13 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/556
18:08:15 <bcotton_> #info Proposed Blocker, plasma-discover, VERIFIED
18:08:16 <bcotton_> #info Ticket vote: FinalBlocker (+4,0,-0) (+kparal, +lruzicka, +bcotton, +kevin)
18:08:18 <bittin> Blocker -1
18:08:18 <bcotton_> #info Ticket vote: FinalFreezeException (+2,0,-0) (+adamwill, +sumantrom)
18:08:21 <bittin> FE +1
18:08:26 <bcotton_> so this one is fixed. we just need to do the paperwork
18:09:05 <geraldosimiao> ack
18:09:08 <bittin> ack
18:09:26 <adamw> let's just call it a blocker and move on
18:09:41 <mboddu> FinalBlocker +1
18:10:30 <bcotton_> proposed #agreed 2015491 - AcceptedBlocker(Final) - This is fixed, but for paperwork purposes, it violates the package manager functionality requirements
18:10:52 <bittin> ack
18:11:03 <geraldosimiao> ack
18:11:04 <sumantro> ack
18:11:07 <mboddu> ack
18:11:11 <coremodule> ack
18:11:15 <pwhalen> ack
18:11:19 <cmurf[m]> just poked my head up and saw this
18:11:28 <cmurf[m]> i've been digging into it the past couple hours 😛
18:11:42 <cmurf[m]> i'm very close to getting a core dump file for upstream folks to look at
18:11:48 <bcotton_> #agreed 2015491 - AcceptedBlocker(Final) - This is fixed, but for paperwork purposes, it violates the package manager functionality requirements
18:12:00 <geraldosimiao> ack
18:12:15 <bcotton_> #topic (2015972) systemd-vconsole-setup.service fails on an arabic system
18:12:17 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2015972
18:12:19 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/561
18:12:19 <cmurf[m]> oops, i mean 2011928, the vexxhost+openstack+hang thing
18:12:20 <bcotton_> #info Proposed Blocker, systemd, NEW
18:12:22 <bcotton_> #info Ticket vote: FinalBlocker (+4,0,-2) (+adamwill, +bcotton, +kevin, +frantisekz, -sgallagh, -lruzicka)
18:13:17 <sumantro> -1 FB , +1 FE
18:13:27 <bittin> -1 FB +1 FE
18:13:38 <pwhalen> +1FB, +1FE
18:13:40 * nirik is still +1 FB, +1 FE
18:13:55 <adamw> i don't see how you vote -1 on this, honestly
18:14:02 <adamw> it very clearly violates the keymap criterion
18:14:12 <mboddu> How hard is it to fix? I feel like its more -1 FB, +1 FE
18:14:20 <adamw> the criterion says "if you pick a keymap it must be used". in this case you picked a keymap and it's not used.
18:14:38 * bittin changes vote to +1 FB
18:14:43 <adamw> mboddu: i *hope* it should be fairly trivial to hack it (symlink fe.map.gz to ara.map.gz)
18:14:44 <Southern_Gentlem> +FB
18:14:46 <nirik> again something we missed before... ;(
18:14:50 <geraldosimiao> that's not new bug heh?
18:14:55 <adamw> i was assuming we'd accept it but waive it, but now we're likely slipping, i'll test that out today.
18:15:09 <geraldosimiao> was on prior releases
18:15:23 <bcotton_> anyone who is -1 care to explain your reasoning?
18:15:27 <coremodule> +1 blocker, +1 FE
18:15:45 <Southern_Gentlem> well if its a blocker then its auto fe correct
18:15:50 <geraldosimiao> +1 FB +1 FE
18:16:07 <geraldosimiao> oppps, right
18:16:34 <geraldosimiao> but vote for waive it
18:16:47 <geraldosimiao> * but I vote for
18:17:19 <StephenGallagher> I explained my reasoning in the ticket
18:17:36 <adamw> Stephen Gallagher: i would waive it mainly on the basis of late discovery
18:17:39 <StephenGallagher> Everyone was agreeing that they'd waive it, which says to me that no one truly believes it deserves to be a blocker
18:17:40 <mboddu> adamw: In that case, I will +1FB because of the easy fix, slipping and majorly criterion
18:17:45 <adamw> if it had been found last week i would be +1 and expect it to be fixed
18:17:48 <Southern_Gentlem> if this was the last bug maybe let it slide but nope we have otherthings
18:18:13 <StephenGallagher> If it wouldn't block the release if it was the last bug, it's not a blocker :)
18:18:41 <bcotton_> i'd block on this if it were the last blocker if it were found last week
18:18:47 <adamw> it would block the release for me if it was the last bug, so long as it had been reported five days before go/no-go.
18:18:59 * adamw high fives bcotton
18:19:13 <geraldosimiao> and its somethign easy to fix or not? requires much more testing to now?
18:19:21 <geraldosimiao> to know
18:19:21 <bcotton_> but in any case, the weight seems to be clearly in the accept column, so
18:19:42 <adamw> geraldosimiao: it should be easy. i can establish that today.
18:19:53 <adamw> if it turns out to be not so easy it should still be fixable, just a bit more work and possibly slightly ugly. :D
18:19:56 <bcotton_> proposed #agreed 2015972 - AcceptedBlocker(Final) - This is clear violation of the "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in at a console" criterion
18:19:58 <Southern_Gentlem> we are already slipping this should be fixed
18:20:00 <bittin> ack
18:20:06 <adamw> ack
18:20:09 <Southern_Gentlem> ack
18:20:11 <pwhalen> ack
18:20:16 <geraldosimiao> ack
18:20:29 <coremodule> ack
18:20:40 <sumantro> ack
18:20:44 <bcotton_> #agreed 2015972 - AcceptedBlocker(Final) - This is clear violation of the "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in at a console" criterion
18:21:31 <bcotton_> okay, i think that's all of the proposed blockrs now (except the cloud one we're potentially punting on)
18:21:59 <bcotton_> did i miss any?
18:22:00 <bittin> so i am guessing no go ?
18:22:28 <bittin> should be all proposed blockers
18:22:45 <bcotton_> #topic Accepted Blockers
18:23:00 <bcotton_> #info Not counting the ones accepted earlier in the meeting, we have 2 accepted blockers
18:23:24 <bcotton_> #info
18:23:26 <bcotton_> (2001837) The switch for Fedora Third Party repositories does not switch them on.
18:23:27 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2001837
18:23:31 <bcotton_> #info Accepted Blocker, fedora-third-party, ASSIGNED
18:23:37 <nirik> so if we slip here we actually slip right? we already used our rain day?
18:23:42 <bcotton_> #info
18:23:43 <bittin> same as #2010740 ?
18:23:44 <bcotton_> (2011322) Discover doesn't seem to find any RPM packages, neither locally installed nor in RPM repos (but just under en_US locale)
18:23:45 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2011322
18:23:51 <bcotton_> whoops
18:23:58 <bcotton_> #info Accepted Blocker, plasma-discover, MODIFIED
18:24:19 <bcotton_> okay, so we have a total of 4 un-VERIFIED blockers
18:24:20 <adamw> errr
18:24:22 <adamw> what are we on
18:24:45 <bcotton_> does anyone want to make a case for waiving all of them? otherwise that settles the matter
18:25:05 <nirik> adamw: we finished going thru proposed and are looking at the 2 we have accepted that are unfixed
18:25:11 <bcotton_> or i guess does anyone have information that the accepted blockers are actually fixed and no one told bugzilla
18:25:18 <mboddu> bcotton_: Yeah, we dont want to slip the release and continue the on time release streak...
18:26:10 <Southern_Gentlem> chnace they can get fixed overnight and we have another go/nogo tomorrow
18:26:17 <nirik> I'm sadly going to say we shouldn't wave those and we should slip a week.
18:26:23 <pwhalen> Most of us arent here tomorrow
18:26:31 <Southern_Gentlem> but tomorrow is refresh day
18:26:36 <nirik> Southern_Gentlem: tomorrow is actually a redhat recharge day, so no redhat people working
18:26:57 <geraldosimiao> hooo, I think #2011322 was fixed!
18:27:00 <nirik> and we are getting to old to be heros. :)
18:27:07 <mboddu> Haha :)
18:27:14 <bcotton_> last call to propose a blanket waive
18:27:19 <mboddu> Sadly we have to slip
18:27:40 <bcotton_> #info We still have outstanding blockers
18:27:46 <adamw> nirik: oh, it is? i didn't know. :
18:27:50 <adamw> * know. :P
18:27:57 <bcotton_> #topic Current status - test matrices
18:27:59 <bcotton_> #link https://fedoraproject.org/wiki/Category:Fedora_35_Test_Results
18:28:06 <nirik> adamw: now you know, and knowing is half the battle!
18:28:18 <bcotton_> We don't need to cover the matrices in great detail, but if there are particular areas you'd like to call attention to, adamw, here's your chance
18:28:38 <adamw> nah, this is going for long enough, let's just call it
18:28:41 <adamw> coverage is pretty good fwiw
18:28:55 <bcotton_> #info Coverage is good
18:29:01 <bcotton_> #info but adam doesn't want to talk about it
18:29:15 <bcotton_> #topic Current status - RC
18:29:21 <bcotton_> #info RC1 is the current release candidate
18:29:29 <bcotton_> #topic Go/No-Go decision
18:29:37 <bittin> +1 No Go ?
18:29:42 <mboddu> Sadly no-go :(
18:29:49 <bcotton_> proposed #agreed F35 Final is NO-GO due to outstanding blockers
18:29:55 <Southern_Gentlem> ack
18:29:58 <bittin> ack
18:30:03 <geraldosimiao> ack
18:30:03 <bcotton_> #agreed F35 Final is NO-GO due to outstanding blockers
18:30:07 <mboddu> ack
18:30:07 <pwhalen> ack
18:30:12 <bittin> ack
18:30:13 <bcotton_> look at me, going through the motions
18:30:26 <bcotton_> #agreed Fedora Linux 35 Final is NO-GO
18:30:27 <bcotton_> #info The next F35 Final Go/No-Go meeting will be Thursday, 2021-10-28 at 1700 UTC
18:30:29 <bcotton_> #info F35 Final shifts to target release date 2: Tuesday 2021-11-02
18:30:38 <mboddu> I wonder how hard is it for bcotton_ to write the agreed statement?
18:30:45 <bcotton_> #action bcotton to announce decision
18:30:56 <bcotton_> #action bcotton to update BZs with blocker decisions
18:31:05 <bcotton_> #topic Open floor
18:31:06 <bcotton_> Anything else we need to discuss before closing?
18:31:08 <adamw> ack
18:31:26 <Southern_Gentlem> nah, time for an Rc cola and moon pie and back at it
18:31:30 <bcotton_> mboddu:  i pre-write the two agreements ahead of time to keep myself emotionally separated
18:31:33 <geraldosimiao> kparal: status?
18:31:33 <bcotton_> Southern_Gentlem++
18:31:51 <pwhalen> bcotton_: heh
18:32:04 <bcotton_> okay, well thanks everyone
18:32:13 <bcotton_> it was a terrific effort :-)
18:32:28 <adamw> yeah, thanks a lot to everyone for testing and fixing
18:32:36 <bcotton_> #endmeeting