16:04:12 <adamw> #startmeeting F32-blocker-review
16:04:12 <zodbot> Meeting started Mon Apr 13 16:04:12 2020 UTC.
16:04:12 <zodbot> This meeting is logged and archived in a public location.
16:04:12 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:12 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:04:12 <adamw> #meetingname F32-blocker-review
16:04:12 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:04:12 <adamw> #topic Roll Call
16:04:15 <bcotton> .hello2
16:04:16 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:04:34 <adamw> ahoyhoy folks, who's here for blocker reviewing funtimes
16:04:47 <cmurf> .hello chrismurphy
16:04:48 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:04:52 <Southern_Gentlem> .hello jbwillia
16:04:53 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:04:59 <coremodule> .hello2
16:05:00 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:05:00 <sumantro> .hello sumantrom
16:05:02 <zodbot> sumantro: sumantrom 'Sumantro Mukherjee' <sumukher@redhat.com>
16:05:15 * coremodule ready to act as secretary for this meeting.
16:07:35 <frantisekz> .hello2
16:07:36 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:08:13 <lruzicka> .hello2
16:08:14 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:10:41 <adamw> sorry, phone
16:14:47 <adamw> alrighty, back
16:14:52 <adamw> #chair frantisekz lruzicka
16:14:52 <zodbot> Current chairs: adamw frantisekz lruzicka
16:14:59 <adamw> i may have to run out to talk to a guy about some bees
16:15:01 <adamw> (long story)
16:15:11 <adamw> if that happens i'll let someone know to take over chairing temporarily
16:15:17 <cmurf> bees are awesome
16:15:19 <bcotton> that's none of our bees-ness
16:15:30 <cmurf> bee keepers are super duper awesome haha
16:15:32 <lruzicka> adamw, we know that you are a busy bee
16:15:40 <adamw> impending boilerplate alert!
16:15:41 <adamw> #topic Introduction
16:15:41 <adamw> Why are we here?
16:15:42 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:15:43 <adamw> #info We'll be following the process outlined at:
16:15:43 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:15:45 <adamw> #info The bugs up for review today are available at:
16:15:46 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:15:48 <adamw> #info The criteria for release blocking bugs can be found at:
16:15:50 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:15:52 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria
16:15:56 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
16:15:58 <adamw> cmurf: bees mysteriously appearing in your spare room: not so awesome
16:16:04 <adamw> #info for Final, we have:
16:16:09 <adamw> #info 5 Proposed Blockers
16:16:09 <adamw> #info 2 Accepted Blockers
16:16:13 <adamw> #info 7 Proposed Freeze Exceptions
16:16:13 <adamw> #info 1 Accepted Freeze Exceptions
16:16:25 <adamw> #info coremodule will secretarialize
16:16:30 <adamw> #topic Proposed Final blockers
16:16:37 <adamw> #info let's start with proposed final blockers!
16:16:43 <adamw> #topic (1821548) schema validation fails
16:16:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1821548
16:16:44 <adamw> #info Proposed Blocker, 389-ds-base, NEW
16:19:04 <bcotton> -1 since the bug didn't reach the stable repo before it was unpushed
16:19:16 <adamw> so, as i said in the bug, this can't really a blocker as it's not "in" 32
16:19:34 <frantisekz> -1 Blocker
16:19:49 <adamw> we never pushed the update stable and now it's not in u-t either.
16:19:50 <sumantro> -1 blocker
16:20:13 <lruzicka> -1 blocker
16:20:33 <lruzicka> and -1 fe (just for sure)
16:20:53 <cmurf> -1
16:20:56 <Southern_Gentlem> -1
16:21:19 <adamw> proposed #agreed 1821548 - RejectedBlocker (Final) - the update that causes this bug never reached stable state and has been unpushed, so the bug is not really affecting F32 at all
16:21:48 <adamw> ok, bee guy is here
16:21:50 <adamw> brb
16:21:56 <frantisekz> ack
16:22:42 <bcotton> ack
16:22:49 <bcotton> (bee r bee)
16:22:53 <lruzicka> ack
16:23:27 <coremodule> ell o ell
16:23:38 <Southern_Gentlem> ack
16:24:06 <lruzicka> #agreed 1821548 - RejectedBlocker (Final) - the update that causes this bug never reached stable state and has been unpushed, so the bug is not really affecting F32 at all
16:24:40 <frantisekz> #topic (1821702) firefox starts in a non-resizeable cropped window instead of a maximized window (on Wayland)
16:24:41 <frantisekz> #link https://bugzilla.redhat.com/show_bug.cgi?id=1821702
16:24:41 <frantisekz> #info Proposed Blocker, gtk3, VERIFIED
16:24:55 <cmurf> i think this is fixed?
16:25:00 <cmurf> seems fixed in ff 75
16:25:23 <frantisekz> hmm, I've tried 74.x with gtk, fixed it too
16:25:38 <frantisekz> anyhow, +1 FE, +0 Blocker, but it doesn't matter too much now
16:26:09 <lruzicka> if it is fixed, is it currently in stable?
16:26:15 <cmurf> what's the basis for blocking?
16:26:26 <frantisekz> no, of course not, we're in freeze
16:26:31 <frantisekz> it's in u-t
16:27:06 <frantisekz> "Proposing as an F32 Final blocker, because either Firefox or the windowing system doesn't work correctly, preventing users from using maximized applications comfortably."
16:27:19 <frantisekz> justification by kparal, seems weak for blocking
16:27:45 <cmurf> definitely +1FE
16:27:57 <bcotton> +0.5 blocker, +1 FE
16:27:58 <lruzicka> yeah, but if that is fixed, it does not matter if we accept the blocker or an FE, the result is the same, aint it?:
16:28:10 <Southern_Gentlem> +1 FE
16:28:10 <cmurf> on the fence for blocker, whether it violates basic functionality
16:28:16 <frantisekz> yeah, it doesn't matter too much lruzicka
16:28:42 <adamw> back
16:28:43 <lruzicka> and does it violate the basic functionality it it cannot be easily maximised?
16:28:45 <adamw> thanks frantisekz
16:28:49 <lruzicka> adamw, welcome
16:28:50 <frantisekz> np adamw :)
16:28:57 <frantisekz> enjoyed my chair powers for a while :D
16:29:11 <adamw> :P
16:29:33 <adamw> my immediate reaction to this was that it's kinda weak, but, i reconsidered a bit on second thought
16:29:55 <adamw> even with chrome being popular these days, firefox is a pretty prominent app
16:30:02 <adamw> if this happens to everyone it looks pretty bad
16:30:11 <cmurf> yeah
16:30:19 <cmurf> so basic function criterion?
16:30:22 <adamw> i'm definitely +1 FE obviously
16:30:41 <adamw> i think blocker or not does matter a bit as kparal suggests the 'fix' comes with a regression
16:30:57 <cmurf> uhoh
16:31:01 <adamw> and the last gtk3 update we attempted went badly
16:31:13 <frantisekz> this one has +5 though
16:31:17 <adamw> if we take this as an FE we're kinda saying 'if we have issues with the update again we can just go back to 3.24.16 and ship that'
16:31:21 <adamw> hmm, hadn't seen that
16:31:29 <adamw> if we take it as blocker we're saying 'we gotta get this fixed right before we ship'
16:31:42 <frantisekz> https://bodhi.fedoraproject.org/updates/FEDORA-2020-ac3dfd7904
16:31:51 <frantisekz> I am using it for a while, didn't hit any issues yet
16:32:40 <lruzicka> adamw, what is the regression you were talking about? None is mentioned on the bug.
16:33:03 <cmurf> i'm at +0.5 blocker
16:33:06 <lruzicka> Except the weird behaviour that frantisekz mentioned.
16:33:38 <frantisekz> "Firefox now starts maximized even if it was closed as not-maximized window previously, but if this is a bug at all, it is a different issue." for the record
16:33:54 <adamw> right
16:34:15 <frantisekz> I'd prefer to pull this on FE basis
16:35:50 <lruzicka> But the 3.26 looks good visually, that would be a pity not to ship it.
16:36:12 <lruzicka> Isn't it worth fixing and shipping?
16:36:45 <lruzicka> I mean, in case adamw has just mentioned
16:38:04 <cmurf> adamw: so when you say 'reconsidered a bit' you mean in favor of blocking?
16:40:33 <adamw> yeah
16:40:46 <adamw> i'm pretty on the fence about blocker
16:41:00 <adamw> maybe we can accept as FE for now and punt on blocker, make a definite decision if it comes back
16:41:10 * adamw counts votes
16:41:10 <bcotton> wfm
16:41:20 <lruzicka> +1 blocker
16:41:25 <lruzicka> just for calculation
16:41:50 <Southern_Gentlem> +1 Punt blocker +1 fe
16:42:40 <adamw> proposed #accepted 1821702 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - it's a close call whether this is bad enough to be a blocker and we don't have a clear decision on that, but we definitely accept it as an FE and the update to fix it has strong positive feedback, so we expect to push that and resolve the bug
16:43:05 <lruzicka> ack
16:43:37 <bcotton> ack
16:44:04 <frantisekz> ack
16:44:21 <cmurf> ack
16:45:19 <adamw> #agreed 1821702 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - it's a close call whether this is bad enough to be a blocker and we don't have a clear decision on that, but we definitely accept it as an FE and the update to fix it has strong positive feedback, so we expect to push that and resolve the bug
16:45:28 <adamw> .fire everyone for not noticing #accepted vs. #agreed
16:45:28 <zodbot> adamw fires everyone for not noticing #accepted vs. #agreed
16:45:44 <adamw> #topic (1814810) Basic graphics mode is necessary to boot laptop with dual Intel/AMD Oland GPU
16:45:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1814810
16:45:44 <adamw> #info Proposed Blocker, kernel, NEW
16:46:19 <coremodule> this is essentially the same bug as 1814015 that we voted on last week
16:46:23 <coremodule> .bug 1814015
16:46:24 <zodbot> coremodule: 1814015 – Freezes and/or lockups in Wayland sessions on systems with dual graphics adapters including NVIDIA (Lenovo P53, P1, Dell XPS 15 9560 ...) - https://bugzilla.redhat.com/1814015
16:46:47 <coremodule> apparently there was quite a bit of backlash and the effects of the bug are further reaching than we originally thought...
16:47:13 <bcotton> do we know this particular bug impacts more than just this particular hardware combination?
16:47:28 <Southern_Gentlem> coremodule,  yes but for years it has been known during install to use basic mode with nvidia etc
16:47:33 <frantisekz> I'd say this is different from 1814015
16:47:44 <frantisekz> it seems from logs
16:48:19 <coremodule> Southern_Gentlem, I know, but these people didn't...
16:49:15 <frantisekz> also, this doesn't affect previous GPU generation (Mars XT), see https://bugzilla.redhat.com/show_bug.cgi?id=1814810#c14
16:49:26 * mboddu is sorta here now, before jumping into another meeting
16:49:30 <adamw> it's the same bug? really?
16:49:38 <cmurf> i can't tell
16:49:40 <adamw> the description of this one says AMD
16:49:47 <adamw> that sounds, uh, not the same thing as NVIDIA
16:49:50 <cmurf> lol
16:49:51 <frantisekz> :D
16:49:57 <adamw> i am not a doctor but i think i heard they aren't friends
16:50:03 <coremodule> ?
16:50:06 <coremodule> thats harsh.
16:50:09 <adamw> =)
16:50:16 <coremodule> the description says nvidia, in bug, comment 1
16:50:38 <coremodule> grrr
16:50:40 <coremodule> i misread
16:50:50 <coremodule> intel =/= nvidia
16:52:35 <frantisekz> I am -1 Blocker here, fixing can be complicated, issue seems limited to particular GPU generation, also, laptops with AMD Oland and Intel CPU aren't that comman as Intel/nVidia combo
16:53:16 <bcotton> -1 blocker for the reasons frantisekz said
16:53:26 <adamw> so uh
16:53:56 <adamw> yeah, i think -1 blocker / +1 FE for me
16:54:09 <bcotton> +1 FE here, too
16:54:21 <adamw> from my five minutes hasty googling, intel/oland dual GPUs does not seem a very common setup at all
16:55:50 <cmurf> +1 FE
16:56:10 <lruzicka> +1 fe
16:56:48 <Southern_Gentlem> +1 fe
16:58:50 <adamw> proposed #agreed 1814810 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as a blocker as we think the range of hardware affected is quite small (dual Intel/AMD Oland GPU systems are not very common), but accepted as an FE as a severe problem not fixable with an update on hardware that *is* affected
16:59:05 <lruzicka> ack
16:59:06 <bcotton> ack
16:59:52 <frantisekz> ack
17:00:00 <Southern_Gentlem> ack
17:00:06 <adamw> #agreed 1814810 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as a blocker as we think the range of hardware affected is quite small (dual Intel/AMD Oland GPU systems are not very common), but accepted as an FE as a severe problem not fixable with an update on hardware that *is* affected
17:00:58 <adamw> #topic (1817708) KDE desktop session will not start when switching between users
17:00:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1817708
17:00:59 <adamw> #info Proposed Blocker, plasma-desktop, NEW
17:01:42 <adamw> so our first mistake here was obviously not getting kparal into the isolation unit
17:01:47 <bcotton> lol
17:01:58 <adamw> we let him near the bug for too long and now it's *lots* of bugs
17:02:52 <lruzicka> at least he could somehow prove I had not seen a KDE ghost.
17:03:38 <adamw> i mean, at this point i'm not even sure what bug we're voting on
17:03:40 <bcotton> i mean technically, "switch users" is not in the set of "shutdown, reboot, log out"
17:04:06 <adamw> comment #13 seems pretty bad
17:04:07 <adamw> yeah
17:04:18 <lruzicka> bcotton, switching users is described in the desktop login test case.
17:04:24 <adamw> i think at least at some point we specifically left "user switching" out of the criterion
17:04:30 <adamw> but then it is in the test case
17:05:10 <adamw> hmmm
17:05:13 <frantisekz> I'd love to say -1, just because I hate blocking on our beloved KDE spin... :)
17:05:20 <adamw> back in January 2015, rdieter said that he doesn't think user switching should block
17:05:41 <adamw> https://lists.fedoraproject.org/pipermail/test/2015-January/124875.html
17:06:19 <adamw> kevin kofler had same opinion (on kde list)
17:06:20 <bcotton> lruzicka: i don't see it in the criteria though
17:06:27 <adamw> oh wait no
17:06:29 <lruzicka> well, I don't agree with him then, because user switching on a multiuser system (which linux is) is a crucial thing
17:06:31 <adamw> he had the other opinion. reading is hard!
17:07:48 <bcotton> i wonder what percentage of users actually do user switching (any number would be believable)
17:07:58 <cmurf> haha
17:08:01 <adamw> so the purpose of that thread as a whole was to add user switching to the criteria, after we I guess decided to accept a user switching bug at a review meeting
17:08:43 <adamw> oh yes. this meeting.
17:08:44 <adamw> https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-01-26/f22-blocker-review.2015-01-26-17.00.html
17:08:47 <cmurf> what constitutes user switching? while logged in as user A, you log in as user B? but does not include user A logging out, then user B logs in?
17:08:49 <lruzicka> bcotton, I do with my wife, not on KDE though
17:08:57 <lruzicka> cmurf, yeah
17:08:58 <cmurf> if there's UI for user switching, I'd say it should work
17:09:01 <adamw> ah, i wasn't running it, that's why i don't remember it. :P
17:09:14 <cmurf> if they don't want to support it and block on it, then remove it from the UI
17:09:14 <adamw> cmurf: right
17:09:35 * cmurf not a fan of giving users razor blades and telling them to go play on the freeway
17:09:56 <lruzicka> cmurf, adamw: yeah, that sounds like a plan, there are other DE that do not have that option
17:10:23 <adamw> it does seem a bit awkward to block on something the maintainer of the desktop specifically doesn't want to block on
17:10:24 <Southern_Gentlem> ok does gnome have this option yes does it work there ?
17:10:29 <adamw> Southern_Gentlem: yes and yes
17:10:42 <bcotton> -0.5 blocker, +1 FE becasue it's not in the criteria and i defer to rex's opinion on this
17:11:02 <Southern_Gentlem> it doesnt ever work all the time in windows 10
17:12:10 <Southern_Gentlem> +1 FE
17:12:21 <adamw> we could ask rex if he's changed his mind since 2015, i guess
17:13:20 <lruzicka> Southern_Gentlem, let's not compare to windows, we can do better
17:13:36 <frantisekz> -1 Blocker/ +1 FE
17:13:48 <lruzicka> Southern_Gentlem, my mother always used to say: "If others tell you to jump of off the cliff .." you know it, rightM
17:14:05 <lruzicka> +1 blocker (+1 FE at least)
17:14:16 * adamw pings rdieter
17:14:57 <cmurf> switching does work in GNOME shell
17:15:04 <lruzicka> cmurf, indeed
17:15:19 <cmurf> bit confused that i see no gdm user when switched (two users logged in)
17:15:43 <cmurf> but when i log out of user B and log back into user A, a gdm user session exists
17:16:09 <cmurf> OIC that gdm user session eventually goes away
17:17:38 <adamw> sigh, rex not responding to pings
17:17:53 <adamw> ideally i'd like to punt here, but we are on a tight time scale
17:18:31 <lruzicka> adamw, now I dont understand the situation ...
17:18:50 <adamw> so basically: in 2015 we agreed to block on this, then rex said he didn't want to, and that never got resolved
17:18:52 <lruzicka> adamw, when we punt and do nothing, the bug escapes the go/no go process, am I correct?
17:18:53 <adamw> that thread petered out there
17:19:00 <adamw> lruzicka: no, it kinda can't
17:19:16 <adamw> lruzicka: we do blocker review at go/no-go and we *must* decide a status for all proposed bugs there
17:19:23 <adamw> we can't punt in that meeting
17:19:41 <adamw> if we punt here, we either resolve it in the next few days or decide at go/no-go
17:20:01 <bcotton> my preference would be for us to decide one way or another in this meeting
17:20:16 <adamw> it seems difficult to do without rdieter here though :/
17:20:29 <lruzicka> adamw, and I can guess that on day D, we will be ready to +1 FE to make it go :D let's try to decide today.
17:20:36 <Southern_Gentlem> whats the vote at
17:21:10 <adamw> we're at +1 / -1.5
17:21:28 <lruzicka> What I think, this problem will rot in KDE for a long long time (as it has been already)
17:22:00 <lruzicka> let's also try to decide, what we expect here and then try some pushing
17:23:37 <adamw> i think i'm gonna vote -1 for now on the basis that we explicitly had a proposal to add this to criteria which was resisted and we never actually *did* add it to the criteria
17:24:27 <lruzicka> ok, so then let's just leave it. We can do +1FE, but this will not have any effect, and it makes a clear candidate for a common bugs.
17:25:18 <lruzicka> so we can also +common bugs and that's it. It sometimes works. Maybe it will work when people will just use it occassionaly.
17:26:18 <adamw> any other votes?
17:26:29 <cmurf> i'm -1 blocker because there's no criterion that applies
17:27:00 <cmurf> well.. fark :D actually it could be argued to be a violation of basic functionality
17:27:05 <cmurf> you present it, it should work
17:27:21 <lruzicka> cmurf, adamw: Upon this, I am suggesting we remove user switching from the desktop login test then.
17:27:36 <adamw> lruzicka: i'd disagree. quite a lot of the tests include actions that aren't part of the criteria
17:27:59 <adamw> we've never intended the tests to cover *only* things that are in the criteria, really. you quite often run a test and hit a bug that isn't a release blocker. that's not a *problem*.
17:28:15 <lruzicka> adamw, I understand your point and I believe that we are missing some of the criteria :D
17:28:30 <adamw> (it's also why i try to keep the cross-referencing stuff in place, so you can easily refer to the actual criterion to tell whether the bug you just hit is a blocker or not...)
17:28:46 <adamw> but we can sort that out later
17:29:00 <cmurf> i'm gonna go -1 blocker, based on adamw's logic...
17:29:18 <adamw> lruzicka: there's actually a ticket for that...
17:29:30 <lruzicka> adamw, we can, I only think there are things that look ugly and shed a bad light on the linux environment, because they are pretty much visible on the first sight.
17:29:32 <cmurf> "we explicitly had a proposal to add this to criteria...never actually *did* add it..."
17:30:07 <lruzicka> cmurf, that can actually mean two things: proposal was dismissed or not finished :D
17:30:16 <cmurf> either way it's ambiguous
17:30:26 <cmurf> so i'll be -1 on ambiguous things
17:30:32 <lruzicka> cmurf, if it was dismissed then, have things changed since?
17:30:34 <adamw> proposed #agreed 1817708 - RejectedBlocker (Final) AcceptedFreezeException (Final) - in 2015 we accepted a GNOME user switch bug as a blocker and proposed a criteria change to explicitly cover it, but rdieter opposed the proposal and it never actually happened; on that basis we can't really accept this as a blocker but do accept it as FE
17:30:47 <adamw> lruzicka: it was effectively just left hanging
17:30:52 <cmurf> ack
17:30:55 <frantisekz> ack
17:30:55 <lruzicka> ack
17:31:09 <adamw> lruzicka: kamil proposed the criteria change. rdieter said "I don't think we should do it". after that there doesn't seem to be any further relevant discussion in the archives i can find
17:31:16 <lruzicka> what about the commong bugs?
17:31:32 <lruzicka> patch perhaps and include it?
17:31:33 <cmurf> is that left hanging?
17:32:26 <cmurf> i have a few friends who use that kind of language: "i'm not sure..." and "i don't think..." translates as a polite form of "it's not possible" rather than actual uncertainty
17:32:27 <lruzicka> adamw, cmurf: seems like we can try to rerun the proposal for 33 :D
17:32:46 <bcotton> ack
17:33:00 <adamw> lruzicka: i don't usually worry too much about calling out commonbugs in agreements
17:33:08 <adamw> that's not strictly speaking something we're "agreeing" on, really
17:33:15 <adamw> anyone can nominate something for commonbugs, it doesn't require a vote
17:33:31 <lruzicka> adamw, so I am nominating it. :)
17:33:45 <adamw> lruzicka: then all you need do is add 'CommonBugs' keyword to the bug :)
17:33:55 <lruzicka> adamw, gotcha :D
17:34:08 <lruzicka> adamw, which field? comments?
17:34:23 <adamw> oh, found more discussion on desktop@ . but still no definite conclusion
17:34:28 <adamw> and the criterion itself definitely was never changed
17:35:01 <adamw> it seems there were kinda two factions, mcatanzaro and kevin kofler favored blocking on user switching, mclasen, rdieter and josh boyer opposed it...
17:35:42 <adamw> we should definitely bring it back up and make a decision on it. but for now i think the agreement is the right call
17:35:52 <adamw> #agreed 1817708 - RejectedBlocker (Final) AcceptedFreezeException (Final) - in 2015 we accepted a GNOME user switch bug as a blocker and proposed a criteria change to explicitly cover it, but rdieter opposed the proposal and it never actually happened; on that basis we can't really accept this as a blocker but do accept it as FE
17:36:23 <adamw> #topic (1815463) Cannot create another user account through KDE System Settings if 'Real Name' field is not filled in
17:36:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1815463
17:36:23 <adamw> #info Proposed Blocker, plasma-user-manager, NEW
17:38:32 <frantisekz> Hmm, what do you think about accepting it as a F33 FinalBlocker? To give upstream time to fix?
17:38:50 <lruzicka> +1, and otherwise same treatment as the previous bug
17:39:07 <bcotton> +1 blocker. i'd almost go with 0 and say fix it in updates, but then who knows when the fix would land
17:40:03 <lruzicka> here he is, rdieter
17:40:06 * rdieter waves
17:42:29 <lruzicka> Let me ask you, rdieter, what is your current opinion on switching user sessions in KDE - do you think it might be release blocking?
17:43:09 <lruzicka> for F33 and later?
17:44:18 <rdieter> good question, since it generally worked in the past, and is a semi-valuable feature, my gut would strongly prefer it to stay working
17:44:51 <adamw> rdieter: the Rex from January 2015 disagrees with you :P
17:44:58 <rdieter> I'll try to poke folks upstream (@kde.org) to see how serious/important they consider it.
17:45:04 <adamw> https://lists.fedoraproject.org/pipermail/kde/2015-January/014180.html
17:45:47 <cmurf> is there a mechanism, other than the late blocker proposal criterion, to make something a blocker for the next release?
17:45:50 <rdieter> I said I would prefer it stay working, still torn if it should be considered blocking or not
17:46:17 <rdieter> that said, decision is easier if kde.org upstream either doesn't or won't take fixing bugs seriously.  then not a blocker
17:46:32 <cmurf> that way we're not stuck blocking this week, but also not leaving things hanging?
17:46:42 <adamw> cmurf: i mean, we can accept something as a blocker for a future release in this meeting. we don't typically consider bugs proposed for the next release, but we *could*. in this case i would not want to do that at this point though, i don't see any value in doing that right now.
17:46:53 <adamw> also i would remind the meeting we are not on that bug right now. :)
17:46:56 <rdieter> so for now, I guess stick with non-blocking (at least until I get good upstream feedback)
17:47:16 <lruzicka> that seems fine with me
17:47:28 <cmurf> ok so the bug now is the Real Name field bug in KDE System Settings
17:47:32 <adamw> yeah
17:47:56 <adamw> well, 'creating a user fails unless you fill that field out'
17:48:00 <cmurf> so its not totally off topic if it's a question of whether upstream will take fixing bugs seriously...
17:48:02 <adamw> we have +2 so far
17:48:02 <lruzicka> rdieter, I will drop you a line in your email to remind you softly :D
17:48:12 <cmurf> i'm +1 based on comment 17
17:48:15 <lruzicka> adamw, for F33 though
17:48:45 <lruzicka> but if there is way to fix it now, so let's do it
17:48:50 <adamw> lruzicka: what?
17:48:56 <adamw> i think there is some confusion here
17:49:07 <adamw> or maybe i'm the only one confused :)
17:49:17 <rdieter> my opinion on this one is (still), -1 to consider it a blocker, if it matters
17:49:19 <adamw> frantisekz: you were proposing accepting *this* bug as f33? on what basis?
17:49:49 <adamw> sorry, i thought the f33 thing was for the previous bug.
17:51:42 <frantisekz> yeah, my proposal was about user cration
17:51:50 <frantisekz> for the other thing, I am -1
17:52:26 <adamw> we are on the user creation bug
17:52:32 <adamw> so let's keep discussion to that
17:52:45 <adamw> so lruzicka, you were voting +1 to this as an f33 blocker?
17:52:51 <adamw> bcotton, what were you voting +1 to?
17:53:19 <bcotton> adamw: i was +1 to BZ 1815463 as a F32 Final Blocker
17:53:46 <lruzicka> I am +1 now or later :D
17:54:54 <lruzicka> adamw, but now it comes the obvious - if that was the only bug left ---- then I am not sure
17:55:01 <frantisekz> I am -1 F32/+1 F33
17:55:25 <lruzicka> adamw, however I long for a fix here.
17:55:27 <cmurf> i'm counting -2/+3
17:57:42 <adamw> i'd like frantisekz's rationale for why it would be a valid decision to reject for f32 but accept for f33...
17:59:17 <frantisekz> to give upstream more time to fix I guess
17:59:27 <frantisekz> sorry for delays in chat, I am making dinner async :D
18:00:12 <frantisekz> also, this wouldn't pass my "if this is last blocker" test
18:00:24 * bcotton slides an empty plate over to frantisekz
18:00:26 <adamw> i mean, if we're willing to release while we wait for upstream to fix it, then we don't really think it's a release blocker
18:00:32 <adamw> so to me your vote is really a -1 :)
18:01:22 <adamw> i'm pretty marginal on this one but taking rex's opinion into account i think i'm a weak -1
18:01:28 <cmurf> mmm, willing to block f33 six months out, not willing to block f32 this week is a practical and subjective position
18:01:37 <lruzicka> cmurf, +1
18:01:46 <adamw> we've known about this bug for longer
18:01:48 <adamw> it's not a late blocker
18:02:03 <cmurf> yeah but we keep punting on actually committing to it being a blocker
18:02:13 <cmurf> that sends an ambiguous message
18:02:24 <adamw> so if we come back in six months and no one has fixed it do we slip f33?
18:02:34 <adamw> or do we just say 'eh okay i guess it's magically not a blocker again'?
18:02:38 <cmurf> haha
18:02:39 <frantisekz> we stop blocking on KDE I'd say...
18:02:39 <frantisekz> :D
18:02:44 <cmurf> right
18:02:50 <adamw> this is literally what rhel used to do
18:03:04 <adamw> and exactly why i'm hard line on this situation
18:03:05 <lruzicka> I think, if we want to do it, there needs to be a clear message about the F33 blocker so that upstream would notice.
18:03:24 <adamw> because that really irks me, i do not like having "blockers" which are not really blockers, just "bugs we really wish someone would fix"
18:04:15 <cmurf> yes
18:04:40 <cmurf> so you're saying this bug is the latter, not the former?
18:04:58 <adamw> that's my read of what people are saying
18:05:06 <adamw> but how about for now we just reject it for f32
18:05:07 <cmurf> errr...it's a bug we want fixed, not a real blocker
18:05:20 <cmurf> that's fine
18:06:03 <adamw> proposed #agreed 1815463 - RejectedBlocker (Final) AcceptedFreezeException (Final) - it's a close call, but with the additional info that populating the 'Real Name' field works around the bug, we agreed this isn't quite serious enough to block the release on, if it is not addressed by Final we will document the workaround in commonbugs
18:06:08 <lruzicka> in my point, you are reading me well
18:06:32 <lruzicka> ack (I like the commong bugs commitment now :D)
18:06:36 <adamw> =)
18:06:40 <bcotton> ack
18:07:26 * lruzicka wonder why he really can't type common bugs and always has an extra G in it.
18:07:54 <adamw> haha
18:08:26 <frantisekz> ack
18:09:53 <adamw> any more acks
18:10:48 <cmurf> ack
18:12:27 <adamw> #agreed 1815463 - RejectedBlocker (Final) AcceptedFreezeException (Final) - it's a close call, but with the additional info that populating the 'Real Name' field works around the bug, we agreed this isn't quite serious enough to block the release on, if it is not addressed by Final we will document the workaround in commonbugs
18:12:41 <adamw> #topic Proposed Final freeze exceptions
18:12:45 <adamw> #info moving on to proposed FEs
18:12:49 <adamw> let's try and do this faster! :)
18:12:53 <adamw> #topic (1823064) podman fails to start, selinux denials
18:12:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1823064
18:12:53 <adamw> #info Proposed Freeze Exceptions, container-selinux, ON_QA
18:13:24 <frantisekz> I wasn't able to reproduce it: https://bugzilla.redhat.com/show_bug.cgi?id=1823064#c3
18:13:43 <frantisekz> (u-t disabled, clean updated F31 upgraded to F32 in VM)
18:14:04 <adamw> yeah, that confuses things a bit
18:14:14 <adamw> i think i'd still give it +1 provisionally
18:14:23 <adamw> on the basis we try and figure that out before pushing anything
18:15:49 <lruzicka> +1 on Adam's reasoning
18:16:39 <bcotton> +1 FE
18:16:51 <bcotton> acutally, no
18:16:55 <bcotton> i changed my mind
18:17:04 <bcotton> -1 FE. it can be fixed in updates
18:17:23 <bcotton> and since frantisekz couldn't reproduce the initial problem, i'm not entirely confident in the update
18:17:37 <adamw> hmm, yeah, i guess fixing with update might be safer...
18:17:42 <frantisekz> -1 FE
18:17:50 <frantisekz> (but, if anybody else can try this...)
18:17:58 <bcotton> unless people are running podman on lives, which doesn't seem like a normal use case
18:19:50 <adamw> proposed #agreed 1823064 - RejectedFreezeException (Final) - as frantisek couldn't reproduce it, this seems unclear, and since there's only marginal benefit to taking this as an FE versus fixing it with an update we don't think it's worthwhile given the uncertainty
18:20:49 <bcotton> patch: s/frantisek/we/  (prefer to speak collectively here instead of calling frantisekz out)
18:21:01 <bcotton> (will not complain if my patch is rejected)
18:21:13 <frantisekz> thanks bcotton :)
18:21:53 <frantisekz> but, ack both with/without patch :)
18:22:29 <adamw> sure
18:23:50 <adamw> any more acks?
18:25:22 <lruzicka> ack
18:25:29 <lruzicka> but have been waiting for the patch
18:25:31 <lruzicka> :)
18:25:32 <adamw> #agreed 1823064 - RejectedFreezeException (Final) - as we couldn't reproduce it, this seems unclear, and since there's only marginal benefit to taking this as an FE versus fixing it with an update we don't think it's worthwhile given the uncertainty
18:25:43 <adamw> patching on the fly! without a safety net!
18:25:49 <adamw> #topic (1823005) earlyoom is not being pulled in when upgrading F30/F31 to F32
18:25:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1823005
18:25:49 <adamw> #info Proposed Freeze Exceptions, earlyoom, VERIFIED
18:25:54 <lruzicka> yay :D
18:26:25 <frantisekz> +1 FE
18:27:36 <lruzicka> +1 FE
18:29:05 <bcotton> +1 FE
18:30:27 <adamw> proposed #agreed 1823005 - AcceptedFreezeException (Final) - pulling this in as an FE is worthwhile to fix upgrades between now and the 0-day stable push
18:32:19 <frantisekz> ack
18:32:27 <lruzicka> ack
18:32:37 <adamw> #agreed 1823005 - AcceptedFreezeException (Final) - pulling this in as an FE is worthwhile to fix upgrades between now and the 0-day stable push
18:32:54 <adamw> #topic (1819296) [abrt] geoclue2: g_type_check_instance(): geoclue killed by SIGSEGV
18:32:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1819296
18:32:54 <adamw> #info Proposed Freeze Exceptions, geoclue2, NEW
18:34:12 <bcotton> i don't see that we have any of the information we were looking for last week
18:34:46 <lruzicka> yeah, on that behalf, I am rather -1
18:34:48 <adamw> cmurf: when you say this is 'transient' you mean you get a crash notification but nothing obviously blows up or loses any data?
18:35:02 <bcotton> but i'm -1 FE because the trigger mechanism as described doesn't apply to live images probably (do people suspend lives?)
18:36:17 <cmurf> i haven't seen this in a while
18:36:43 <adamw> think i'm -1 too on current info
18:36:59 <cmurf> but by transient i mean it doesn't always happen; when it crashes i see no other consequence
18:38:05 <adamw> proposed #agreed 1819296 - RejectedFreezeException (Final) - there's too much uncertainty here at present and the problem does not seem severe enough to merit considering a freeze exception, this can be investigated and fixed with a post-release update
18:38:37 <lruzicka> ack
18:39:00 <bcotton> ack
18:39:06 <frantisekz> ack
18:39:53 <cmurf> ack
18:39:59 <adamw> #agreed 1819296 - RejectedFreezeException (Final) - there's too much uncertainty here at present and the problem does not seem severe enough to merit considering a freeze exception, this can be investigated and fixed with a post-release update
18:40:05 <adamw> #topic (1822336) Default Utilities folder renamed to X-GNOME-Utilities.directory
18:40:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1822336
18:40:05 <adamw> #info Proposed Freeze Exceptions, gnome-shell, NEW
18:40:13 <adamw> argh why does this sort of thing keep happening
18:40:20 <lruzicka> +1 FE
18:40:31 <bcotton> +1 FE
18:40:39 <bcotton> because software is terrible :-(
18:40:50 <lruzicka> it is annoying, once I was looking for it like a minute
18:41:38 <frantisekz> +1 FE
18:42:05 <adamw> definitely +1 FE
18:43:08 <adamw> proposed #agreed 1822336 - AcceptedFreezeException (Final) - this is a very prominent error, even though cosmetic, and cannot be fixed for the live environment with a post-release update
18:43:11 <Southern_Gentlem> +1FE
18:43:14 <frantisekz> ack
18:43:36 <Southern_Gentlem> ack
18:43:48 <lruzicka> ack
18:43:51 <bcotton> ack
18:44:29 <adamw> #agreed 1822336 - AcceptedFreezeException (Final) - this is a very prominent error, even though cosmetic, and cannot be fixed for the live environment with a post-release update
18:44:37 <adamw> #topic (1822992) gnome-weather displays no cloud conditions and unknown temperature for autodetected locations
18:44:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1822992
18:44:37 <adamw> #info Proposed Freeze Exceptions, gnome-weather, VERIFIED
18:44:43 <frantisekz> +1 FE
18:45:00 <Southern_Gentlem> +1fe
18:45:51 <bcotton> +1 FE
18:46:05 <lruzicka> +1fe
18:47:00 <adamw> proposed #agreed 1822992 - AcceptedFreezeException (Final) - this is a fairly visible bug in a core GNOME component and cannot be fixed with an update for the live environment
18:47:06 <frantisekz> ack
18:47:06 <bcotton> ack
18:47:36 <lruzicka> ack
18:47:41 <adamw> #agreed 1822992 - AcceptedFreezeException (Final) - this is a fairly visible bug in a core GNOME component and cannot be fixed with an update for the live environment
18:47:42 <adamw> #topic (1808767) X crashes on i915 GPU with SNA 2D acceleration
18:47:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1808767
18:47:42 <adamw> #info Proposed Freeze Exceptions, xorg-x11-drv-intel, ON_QA
18:48:00 <frantisekz> +1 FE
18:48:28 <adamw> +1
18:48:55 <bcotton> +1 FE
18:49:09 <lruzicka> +1 FE
18:50:55 <adamw> proposed #agreed 1808767 - AcceptedFreezeException (Final) - the range of hardware this affects is quite limited, but it is a serious problem on those systems and cannot be fully addressed with an update
18:51:01 <bcotton> ack
18:51:03 <frantisekz> ack
18:52:12 <lruzicka> ack
18:52:17 <adamw> #agreed 1808767 - AcceptedFreezeException (Final) - the range of hardware this affects is quite limited, but it is a serious problem on those systems and cannot be fully addressed with an update
18:52:29 <adamw> #topic (1820614) zezere-ignition copies the ssh keys to '.ssh/authorized_keys.d/ignition'
18:52:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1820614
18:52:29 <adamw> #info Proposed Freeze Exceptions, zezere, ON_QA
18:53:23 <bcotton> +1 FE to fix IoT
18:53:27 <frantisekz> +1 FE
18:53:37 <lruzicka> +1FE
18:54:25 <adamw> proposed #agreed 1820614 - AcceptedFreezeException (Final) - this is a significant issue for initial deployment and provisioning of IoT instances, cannot be addressed with a post-release update
18:54:26 <cmurf> +1 FE
18:54:56 <bcotton> ack
18:54:57 <frantisekz> ack
18:55:00 <lruzicka> just curious - where does the "zezere" name originates from? in Czech it almost means "it will feed itself on"
18:55:04 <lruzicka> ack
18:57:00 * adamw has no idea
18:57:03 <adamw> #agreed 1820614 - AcceptedFreezeException (Final) - this is a significant issue for initial deployment and provisioning of IoT instances, cannot be addressed with a post-release update
18:57:17 <adamw> ok, that is all the proposed bugs, just on time
18:57:33 <adamw> #topic Accepted blocker review
18:57:38 <adamw> #info both accepted blockers are VERIFIED
18:57:42 <adamw> #topic Open floor
18:57:49 <adamw> any other business, folks? late proposals, etc?
18:58:15 <bcotton> have we taken kparal's keyboard away?
18:59:14 <adamw> i think he's been taken to the isolation unit
18:59:26 <frantisekz> :D
18:59:37 <lruzicka> I don't think so, he is very cautious about that.
18:59:54 <adamw> alllllllrighty
18:59:58 <adamw> thanks for coming, everyone
19:00:07 <lruzicka> thanks for leading the way
19:00:20 <lruzicka> have a nice time everybody and good night :D
19:00:33 <frantisekz> thanks everybody and adamw for leading the meeting :)
19:00:34 <adamw> +1!
19:00:35 <adamw> #endmeeting