17:01:49 <bcotton> #startmeeting F36 Final Go/No-Go meeting
17:01:50 <zodbot> Meeting started Thu Apr 28 17:01:49 2022 UTC.
17:01:50 <zodbot> This meeting is logged and archived in a public location.
17:01:50 <zodbot> The chair is bcotton. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:01:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:50 <zodbot> The meeting name has been set to 'f36_final_go/no-go_meeting'
17:01:50 <bcotton> #meetingname F36-Final-Go_No_Go-meeting
17:01:50 <zodbot> The meeting name has been set to 'f36-final-go_no_go-meeting'
17:02:33 <bcotton> #topic Roll Call
17:02:34 <bcotton> who's joining us for what may be our most entertaining go/no-go yet
17:02:34 <sgallagh> .hi
17:02:34 <VipulSiddharth[m> .hello siddharthvipul1
17:02:35 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:02:38 <zodbot> VipulSiddharth[m: siddharthvipul1 'Vipul Siddharth' <siddharthvipul1@gmail.com>
17:02:39 <mhroncok> .hello churchyard
17:02:41 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:02:43 <coremodule> .hello2
17:02:44 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:02:47 <jednorozec> .hello humaton
17:02:48 <zodbot> jednorozec: humaton 'Tomáš Hrčka' <thrcka@redhat.com>
17:02:59 <adamw> .hello adamwill
17:03:00 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:03:25 <mboddu> .hello mohanboddu
17:03:26 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:03:45 <bcotton> #chair bcotton_
17:03:45 <zodbot> Current chairs: bcotton bcotton_
17:04:29 <bcotton_> #topic Purpose of this meeting
17:04:30 <bcotton_> #info Purpose of this meeting is to check whether or not F36 Final is ready for shipment, according to the release criteria.
17:04:32 <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 Beta are fully completed
17:05:03 <bcotton_> #topic Current status - blockers
17:05:05 <bcotton_> #link https://qa.fedoraproject.org/blockerbugs/milestone/36/final/buglist
17:05:14 <bcotton_> #info 8 Proposed Blockers
17:05:15 <bcotton_> #info 4 Accepted Blockers
17:05:23 <bcotton_> okay, everyone, fasten your seat belts!
17:05:31 <bcotton_> #topic (2079400) upgrade from Fedora 35 fails
17:05:33 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079400
17:05:34 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/789
17:05:36 <bcotton_> #info Proposed Blocker, dogtag-pki, NEW
17:05:37 <bcotton_> #info Ticket vote: FinalBlocker (+0,0,-1) (-adamwill)
17:06:24 <lruzicka> .hello2
17:06:25 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:06:30 <adamw> dgilmore_: reported that upgrading his f35 FreeIPA server to F36 didn't work. we have an openQA test that does this starting from clean f35 and it works.
17:06:49 <adamw> anyone else tried a freeipa server upgrade?
17:07:50 * sumantro i shere
17:08:20 <lruzicka> sumantro, what do you shere?
17:08:49 <sgallagh> lruzicka: I think that was “is here”
17:08:51 <sumantro> lruzicka, typo *is
17:08:58 <lruzicka> aaahh
17:09:16 <lruzicka> I just glanced at it and wanted to know more :D
17:09:21 <bcotton_> so given the lack of information, i think i have to be -1 by default
17:09:26 <lruzicka> me too
17:09:55 <sumantro> me too
17:09:58 <VipulSiddharth[m> bcotton_: makes sense
17:11:24 <bcotton_> proposed #agreed 2079400 - RejectedBlocker(Final) - The openQA tests succeed and there's insufficient information to call this a blocker.
17:11:35 <sgallagh> +1
17:11:43 <adamw> ack
17:11:47 <sgallagh> ack
17:11:47 <coremodule> ack
17:11:57 <sgallagh> My +1 was for the proposed #agreed, FTR
17:12:06 <nirik> morning (late)
17:12:18 <jednorozec> ack
17:12:18 <Southern_Gentlem> afternoon (late)
17:12:33 <mboddu> There seems to be a workaround (kinda), so ack
17:12:36 <lruzicka> ack
17:12:38 <mhroncok> ack
17:12:45 <sumantro> ack
17:14:02 <frantisekz> ack
17:14:06 <frantisekz> .hello2
17:14:07 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:15:07 <adamw> did we lose ben
17:15:17 <adamw> everyone check behind your couch
17:15:24 <bcotton_> sorry
17:15:33 <bcotton_> #agreed 2079400 - RejectedBlocker(Final) - The openQA tests succeed and there's insufficient information to call this a blocker.
17:15:45 <lruzicka> adamw, he was not there
17:15:48 <bcotton_> in the process of preparing to move and the landlord needed a couple of questions answered
17:16:01 <bcotton_> #topic (2079356) when deleting multiple events, only the last one is deleted, others reappear after app restart
17:16:03 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079356
17:16:04 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/788
17:16:06 <bcotton_> #info Proposed Blocker, gnome-calendar, NEW
17:16:07 <bcotton_> #info Ticket vote: FinalBlocker (+3,1,-3) (+bcotton, +catanzaro, +asciiwolf, kparal, -geraldosimiao, -lruzicka, -humaton)
17:16:11 <adamw> okay, so
17:16:22 <sgallagh> adamw: Weirdly, that's just where I found him!
17:16:31 <adamw> can we maybe talk about this area as a whole before going bug-by-bug?
17:16:44 <bcotton_> #chair adamw
17:16:44 <zodbot> Current chairs: adamw bcotton bcotton_
17:16:44 <lruzicka> yes
17:16:48 * nirik subscribes to adamw's newsletter
17:16:50 <bcotton_> let's. topic as you see fit
17:16:52 <adamw> since we have, like, eight bugs which are basically "this GNOME app has a fairly obvious bug"
17:17:34 <adamw> #topic GNOME and the "Default application functionality" criterion
17:18:13 <adamw> so the background here is: we have this criterion - https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality - which says that for Workstation, all apps installed by default "must start successfully and withstand a basic functionality test"
17:18:14 <mhroncok> we could remove the calendar from default app set :D
17:18:19 * mboddu thinking, Uh oh, coming up on release criterion during the go/no-go meeting
17:18:28 <adamw> we further define basic functionality as "Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention."
17:18:32 <geraldosimiao> .hello geraldosimiao
17:18:33 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
17:19:13 <adamw> and we have a test case - https://fedoraproject.org/wiki/QA:Testcase_desktop_app_basic
17:19:55 <sgallagh> Do we not have OpenQA tests for any of these?
17:20:12 <sgallagh> (No accusation, just curious how we got this far without noticing)
17:20:26 <adamw> Stephen Gallagher: no. we have openqa tests for gnome-text-editor, evince, and eog currently
17:20:55 <adamw> implementing and maintaining tests that exercise applications is a reasonable amount of work
17:21:01 <adamw> so, yes, good question
17:21:05 <sgallagh> Understood
17:21:08 <adamw> and we (QA team) talked about it yesterday
17:21:15 <lruzicka> sgallagh, the application tests require quite a space to store all the graphical needles, so we have not planned to test all the gnome applications automatically until now
17:21:27 <adamw> so we did run this test at Beta, but the person who ran it didn't work the applications as hard as the people who ran it for Final this week
17:21:33 <lruzicka> sgallagh, but we might reconsider
17:22:20 <adamw> the criteria and test case are, obviously, subject to...interpretation. cynically speaking, you can run the test "intending to pass" - open each app, do something *really* basic, say "yup that's good" and move on - or you can run the test with a more serious intent of trying to find something broken
17:22:46 <sgallagh> Do all of these reported potential blockers have the same root cause and is that root cause the one addressed in RC 1.2?
17:22:56 <adamw> Stephen Gallagher: no.
17:23:05 <sgallagh> Too much to hope for, I guess
17:23:23 <adamw> a couple of the contacts bugs might have the same cause, but on the whole, they're all different bugs that aren't fixed.
17:23:44 * nirik looks to see what apps we are talking about here.
17:23:54 <adamw> it's likely at least several of them have existed for some time. some might even be in f35 (not sure if we've checked)
17:24:05 <nirik> calendar, contacts, totem
17:24:12 <lruzicka> nirik, Contacts, Calendar, Video
17:24:18 <adamw> nirik: gnome contacts, gnome calendar, and one in totem
17:24:30 <coremodule> I checked calendar in f35 and couldn't reproduce... didn't check the other apps
17:24:52 <Southern_Gentlem> has anyone confirmed the calendar issue
17:25:01 <lruzicka> Southern_Gentlem, which one?
17:25:22 <Southern_Gentlem> couldnt do 3 meeting
17:25:27 * mhroncok brb
17:25:29 <mboddu> adamw: On the topic of testing, I wanna go with the 2nd option, "run the tests with serious intent" as I dont want us to face the same situation again
17:25:30 <adamw> it's also been suggested that these apps are not very commonly used, which would contribute to basic bugs in them not being found until now
17:25:34 <Southern_Gentlem> i did six in may tesitng
17:26:05 <coremodule> yes, i have confirmed the "when deleting multiple events, only the last one is deleted" issue
17:26:06 <lruzicka> I could do 4 meetings and then stopped.
17:26:10 <nirik> adamw: they may also not be apps commonly used on live sessions... ie, you don't usually setup your calendar on a live boot, you install and do it (ie, they could be fixed in updates?)
17:26:16 <adamw> Southern_Gentlem: doesn't look like anyone reproduced that one yet
17:26:35 <adamw> nirik: yes, that's a consideration too - but the criteria don't really give any wiggle room there as they stand
17:26:54 * nirik nods. Just noting that datapoint.
17:27:33 <adamw> in discussion of this bug over the last few days, here's some quotes from desktop team
17:27:34 <adamw> "personally i don't think that contacts or photos are critical enough to block the release on. nor do i think that we should be dropping apps off the install media at this point"
17:27:43 <adamw> (allan day)
17:27:55 <mboddu> I agree with adamw
17:28:07 <adamw> "fyi: gnome-contacts and gnome-calendar have never actually worked reliably, bugs there are not surprising" - Michael Catanzaro
17:28:08 <lruzicka> +1
17:28:34 <nirik> so, sounds like that critera needs adjustment... "all apps except these we don't care so much about"
17:28:41 <lruzicka> adamw, Also Michael said he would have known about that behaviour earlier.
17:28:43 <mboddu> adamw: But can we test these test cases for next release? Maybe that is something we should look at
17:28:58 <adamw> nirik: so, that's interesting too: because we did make that adjustment for KDE recently
17:29:01 <adamw> this requirement only applies to Workstation
17:29:02 <sgallagh> Except that these are fit-and-finish criteria too
17:29:18 <adamw> for KDE the requirement applies to a shorter list of specific applications (or, technically, the default application for each of a short list of specified purposes)
17:29:27 <sgallagh> We don't want some reviewer playing around with the Live image and reporting that the Calendar is broken six ways from Sunday.
17:29:32 <adamw> however, my recollection is that desktop team specifically didn't want that change applied to Workstation
17:29:40 <adamw> i'll see if i can find the discussion
17:29:54 <adamw> Stephen Gallagher: yes, that was the initial point of the criterion, indeed
17:30:17 <adamw> though formal three-page distro reviews are kinda less of a Thing these days, i feel
17:30:17 <sgallagh> Right, I'm noting that nirik's point about "fixable with an update" may not be sufficient in that light
17:30:25 <adamw> (also Ubuntu just shipped with, presumably, most of these bugs, and nobody's crucified them for it yet)(
17:30:30 <nirik> in any case, (no matter how we process it), I don't think blocking on these makes sense, if the folks who would be fixing them don't think they are blockers and thus may not work on them in any specific time
17:30:48 <adamw> anyway, sorry for the spiel, just trying to give a general background here for us to consider all these bugs in light of
17:31:04 <adamw> and explain why this has suddenly cropped up now
17:31:07 <sgallagh> No apology required. It's important information
17:31:27 <jednorozec> yeah the context is important
17:31:33 * mboddu bbiab
17:31:42 <adamw> so, one final piece
17:32:24 <adamw> up till a couple hours ago, i was gonna broadly recommend that whichever of these we take as blockers, we waive as late blockers, because they really were all proposed very late and there is the issue i mentioned of the ambiguity about exactly how high of a 'basic functionality' standard we really want to apply
17:32:57 <adamw> but that was based on the assumption these would be the only blockers. we now have a pretty viable other blocker candidate
17:33:10 <coremodule> Agreed. It seems to all come down to whether or not we think that these apps are "...at least broadly capable of [their] most basic expected operations..."
17:33:17 <adamw> so i'd actually suggest we discuss that one first, as it seems to me like the one folks would be most likely to want to take and not waive
17:33:26 <nirik> +1
17:33:35 <adamw> and our decision on that might influence exactly what we want to do about the desktop blockers
17:33:36 <bcotton_> adamw: is that the wpa_supplicant bug?
17:33:44 <adamw> yup
17:34:00 <bcotton_> okay, well then if everyone is ready, we can move on to that one
17:34:06 <lruzicka> sure
17:34:09 * bcotton_ waits briefly for objections
17:34:13 <sgallagh> Yeah, that one's going to be a doozy
17:34:16 <lruzicka> let's do it
17:34:17 <coremodule> +1 bcotton
17:34:39 <bcotton_> #topic (2072070) Connection to wireless network fails without explanation when other end does not support secure renegotiation
17:34:40 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2072070
17:34:42 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/729
17:34:43 <bcotton_> #info Proposed Blocker, wpa_supplicant, NEW
17:34:45 <bcotton_> #info Ticket vote: FinalBlocker (+2,0,-0) (+lruzicka, +asciiwolf)
17:34:46 <bcotton_> #info Ticket vote: FinalFreezeException (+2,0,-0) (+lruzicka, +asciiwolf)
17:35:28 <nirik> it's hard to tell how common that kind of setup is...
17:35:53 <adamw> so, we previously voted on this, but i think at that time we were operating broadly under the understanding that, when someone was affected by this, it indicated a bug or misconfiguration of the router, and that was likely to be unusual and something the network admin should fix
17:36:24 <adamw> also that it could be properly worked around with a relatively simple configuration file tweak we could document
17:36:53 <adamw> however, James Ralston provided a really valuable clarification on several elements at https://bugzilla.redhat.com/show_bug.cgi?id=2072070#c24 (thanks James) which definitely change the equation somewhat for me
17:37:01 <sgallagh> Right, and it turns out that it's 1) a not uncommon router misconfiguration and 2) much harder for a user to fix properly'
17:37:40 * nirik is reading the wall of text
17:37:42 <adamw> also, it's arguably not even really a 'misconfiguration' in this case; "unsafe" renegotiation for this specific use case is not really a security issue (if i'm following correctly)
17:38:03 <jednorozec> this is a relatively common setup in schools over here
17:38:11 <adamw> and upstream openssl documentation of the change does seem to suggest that it's reasonable for apps that use openssl to allow this in situations where it's not really a security problem
17:39:12 <adamw> Thomas Haller (our NetworkManager admin) says James' post is accurate and he agrees that for F36, configuring wpa_supplicant to allow this would be the right thing to do
17:39:46 <Southern_Gentlem> link to RC and i will test this now
17:39:56 <adamw> i wish we'd had this info earlier (and I'm guilty of not figuring it out when I did look into this issue before), but we're here now :|
17:40:15 <adamw> Southern_Gentlem: links at the top of https://fedoraproject.org/wiki/Test_Results:Fedora_36_RC_1.2_Installation .
17:40:30 <bcotton_> so this is definitely a "wow, we're going to get a lot of angry people over this" kind of bug
17:40:38 <sgallagh> I wish I could say "okay, let's fix it as a 0day", but network connection issues inherently make that hard.
17:40:44 <bcotton_> i'm trying to figure out what criterion this violates
17:40:49 <nirik> it's still not super clear how widespread it is... but I guess we will never know
17:41:07 <bcotton_> nirik: well if we release it, we'll find out pretty quickly ;-)
17:41:12 <sgallagh> bcotton_: Ability to upgrade via DNF without a wired connection at the minimum
17:41:21 <adamw> yeah. we *could* argue "oh this is a weird wifi thing, just install from live or over wired", but...I get a kinda bad feeling about it
17:41:52 <nirik> many people use live media for network things... ;(
17:42:05 <sgallagh> Also, university students are definitely among our largest early-adopter crowds
17:42:12 <sgallagh> This would disproportionately affect them
17:42:14 <bcotton_> yeah, and a lot of devices that would be affected like this don't ship with wired ethernet ports over the last few years
17:42:23 <Southern_Gentlem> thus the reason i am testing i work at a uni
17:42:29 <adamw> bcotton_: it'd violate any of the desktop criteria that imply networking - like the web browser ones - and any 'install must work' criteria, in the case of needing to use this kind of wifi network
17:42:37 <adamw> so, conditional violation, which means it's a judgment call for us
17:42:42 <sgallagh> I'm leaning towards a regrettable blocker +1
17:42:48 <adamw> we've been talking about adding explicit networking criteria, but we didn't do it yet
17:42:56 <bcotton_> yeah, i'm a +1 here too
17:43:03 <nirik> sadly, I guess I am too...
17:43:13 <nirik> do we have any info from the wpa_supplicant maintainer?
17:43:14 <Southern_Gentlem> give me 10min
17:43:19 <mhroncok> +1
17:43:20 <adamw> yeah, i'm leaning that way. really sucks to slip another week, but...
17:43:26 <bcotton_> on the newly-invented "i am on fedora's twitter account and do not wish to subject myself to this" criterion
17:43:29 * sgallagh hands Southern_Gentlem a clock
17:43:57 <adamw> nirik: i don't believe so, but i'd count thomas as being a 'subject matter expert' in that general area, it's all kinda interconnected
17:44:19 <lruzicka> I believe that we could use this bug to win another week by claiming that we decided to fix it to help our users (and fix the rest, too)
17:44:37 <lruzicka> and let our users know
17:44:49 <copperi[m]> 🙄
17:44:56 <adamw> there is also an ulterior motive for slipping a week which we can hotly deny: it'd help with https://bugzilla.redhat.com/show_bug.cgi?id=2056303
17:45:08 <adamw> (if any journalists are reading, i deny i said that)
17:45:27 <nirik> well, this puts us in another not ideal situation tho
17:45:40 <sgallagh> I hit that one when upgrading pre-beta as well
17:45:45 <adamw> nirik: which is?
17:45:56 <nirik> if we accept those gnome apps as blockers, then we only have a week to fix them... and we can't waive them next week for being 'too close to the go/nogo'
17:45:58 <sgallagh> This may in fact be the root cause of the FreeIPA upgrade issue as well
17:46:22 <adamw> we can still waive them for being proposed late, i think
17:46:23 <adamw> let me read the wording
17:46:26 * coremodule scribbles furiously into his notepad, lights off a flashbulb as he snaps a photo, and heads off to the nearest phonebooth to tell headquarters about adamw's admission of ulterior motive...
17:46:45 <lruzicka> coremodule, another watergate?
17:46:50 <adamw> "bugs proposed as blockers 5 days or fewer before the scheduled Go_No_Go_Meeting for a milestone release (Beta or Final) can be considered under this policy"
17:47:03 <adamw> it says "scheduled Go_No_Go_Meeting". this one was scheduled. we're good! :D
17:47:05 <nirik> ah ha. ok.
17:47:13 <nirik> and proposed
17:47:19 <sgallagh> coremodule: It will probably take you at least a week to find a working phonebooth
17:47:57 <adamw> Stephen Gallagher: there's still a surprising number of 'em around here. there's one in the skytrain station! and the ferry terminal is full of them for some reason.
17:48:08 <nirik> ok, so we are waiting for Southern_Gentlem to test here? I guess that gives us another datapoint, but I don't think it will change votes too much...
17:48:12 <copperi[m]> adamw: in working order ?
17:48:15 <sgallagh> In the latter case, maybe it's for all the people who drop their phones on the ferry?
17:48:23 <adamw> copperi: yup
17:48:33 <adamw> okay, so
17:48:50 <lruzicka> sgallagh, or when you fall into the water and come from it half naked without anything
17:48:57 <sgallagh> ISTR an article a while back where scuba divers were finding thousands of dollars worth of phones in Boston harbor
17:49:01 <adamw> is anyone -1?
17:49:10 <bcotton_> proposed #agreed 2072070 - AcceptedBlocker(Final) - This bug is a conditional violation of all criteria that imply network access and any 'install must work' criteria in cases where a WiFi network is used
17:49:29 <lruzicka> ack
17:49:35 <sgallagh> sad ack
17:49:37 <mhroncok> ack
17:49:39 <jednorozec> ack
17:49:43 <adamw> patch: "an affected WiFi network"
17:49:43 <copperi[m]> ack
17:49:47 <adamw> it's not all wifi in the world ever.
17:50:05 <lruzicka> patch +1
17:50:06 <mhroncok> that would be fun
17:50:35 <bcotton_> #agreed 2072070 - AcceptedBlocker(Final) - This bug is a conditional violation of all criteria that imply network access and any 'install must work' criteria in cases where an affected WiFi network is used
17:50:49 <bcotton_> well...here we are then
17:51:18 <bcotton_> shall we continue with the rest of the proposed blockers or leave that to ticket voting/monday's blocker review meeting?
17:51:33 <Southern_Gentlem> we are here
17:51:42 <sgallagh> We should vote on them
17:52:04 <sgallagh> If they ARE blockers, we don't want to burn the days that the GNOME folks could be working on them
17:52:04 <lruzicka> let's vote on them
17:52:18 <bcotton_> alrightly, let's do it
17:52:40 <bcotton_> back to...
17:52:42 <bcotton_> #topic (2079356) when deleting multiple events, only the last one is deleted, others reappear after app restart
17:52:44 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079356
17:52:45 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/788
17:52:47 <bcotton_> #info Proposed Blocker, gnome-calendar, NEW
17:52:48 <bcotton_> #info Ticket vote: FinalBlocker (+3,1,-3) (+bcotton, +catanzaro, +asciiwolf, kparal, -geraldosimiao, -lruzicka, -humaton)
17:53:04 <Southern_Gentlem> -1
17:53:06 <sgallagh> I'm -1 on this one since there's a simple workaround of deleting one-by-one
17:53:20 <mhroncok> 0
17:53:22 <nirik> +1 I guess. I think we should revisit the critera after release tho
17:53:24 <sgallagh> Call that a CommonBugs and fix it in an update
17:53:32 <adamw> well, there's a simple workaround, but the problem isn't obvious
17:53:35 <adamw> it looks like it worked
17:54:06 <adamw> you only find out it failed when you restart the app. and that might be days later, and you might not think to check that an appointment you thought you'd deleted was actually deleted.
17:54:08 <sgallagh> It fails my "last blocker at Go/No-Go" test
17:54:33 <adamw> yeah, it probably fails mine too. i'm in the 'run this test to pass' school, to be clear. when i used to run this test, i would've run the app, added one event, then said 'yup it works' and moved on...
17:54:50 <adamw> so broadly i'm -1
17:54:57 <lruzicka> When we advise in CommonBugs that when deleting the events, one should wait until the message disappears or one should dismiss it with the icon, it will work.
17:55:14 <lruzicka> so the basic functionality sort of is there.
17:55:45 <nirik> hum, ok, I guess I can be -1 based on that...
17:56:01 <lruzicka> by the way, in real life you would not be able to delete many events one after another, you would spend some time thinking and looking for them
17:56:30 <adamw> bcotton_: and Michael Catanzaro are +1, does that hold?
17:56:31 <lruzicka> which would give the application the time to prepare for another deletion
17:56:36 <sgallagh> lruzicka: Unless you were mass-deleting a set of events you accidentally duplicated
17:56:38 <nirik> well, if you say signed up for 6 talks in a row, then couldn't attend the event?
17:56:39 <coremodule> -1 blocker
17:56:49 <sumantro> -1 blocker too
17:56:51 <bcotton_> i guess i'll change to 0
17:57:01 <lruzicka> sgallagh, how do you do it? I did not find a way to delete multiple events at one
17:57:03 <lruzicka> once
17:57:05 <copperi[m]> -1
17:57:12 <sgallagh> I agree it's not good behavior, but I remain -1
17:57:20 <bcotton_> i'm still feeling a little "this is a thing people would reasonably expect to be able to do", but i also want to be popular
17:57:30 <lruzicka> sgallagh, it's right click -> edit -> delete
17:57:37 <adamw> btw, i found the discussion of the criterion change from 2020. it's a bit different from how I remembered it. it seems we (QA team) decided the scope - to keep the criterion applying to all apps on Workstation x86_64, but tighten it for KDE and Workstation aarch64 - and desktop team just agreed to that (rather than actively suggesting we keep the broad scope)
17:58:02 <adamw> https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/HNXF7WCYQ7RAKMNGCIOXCBXERBAK44TK/ is the proposal, the discussion happened the next month (march) and is mostly people saying "sure whatever"
17:58:04 <sgallagh> bcotton_: Being popular isn't all it's cracked up to be. It's exhausting ;-)
17:58:25 <adamw> bcotton_: i both agree it's a bug people using the app in anger could plausibly run into, and vote -1. :D
17:59:29 <sgallagh> FTR, I vote +1 FE in case it gets fixed in the meantime
17:59:39 <adamw> yeah, +1 FE
17:59:39 <bcotton_> ah yeah, good idea
17:59:41 <bcotton_> +1 FE
18:00:11 <nirik> yep. +1 FE definitely.
18:00:18 <adamw> i think we're at about -7 / +2 at this point, so we can call this one
18:01:18 <coremodule> +1 FE
18:01:25 <lruzicka> +1 FE surely
18:01:33 <sumantro> +1 FE
18:01:40 <copperi[m]> +1 FE
18:01:49 <lruzicka> +1 CommonBugs if not fixed
18:02:35 * nirik thinks we lost bcotton_ again. ;) Perhaps one of the qa peeps would like to run the review?
18:02:36 * mboddu is back
18:02:43 <bcotton_> im here
18:02:59 <bcotton_> proposed #agreed 2079356 - RejectedBlocker(Final) AcceptedFreezeException(Final) - This does not violate the "Basic Functionality" criterion but is worth fixing if possible
18:03:12 <nirik> ack
18:03:19 <coremodule> ack
18:03:20 <lruzicka> ack
18:03:30 <jednorozec> ack
18:03:31 <copperi[m]> ack
18:03:32 <sumantro> ack
18:03:33 <sgallagh> ack
18:03:48 <adamw> ack
18:04:02 <bcotton_> #agreed 2079356 - RejectedBlocker(Final) AcceptedFreezeException(Final) - This does not violate the "Basic Functionality" criterion but is worth fixing if possible
18:04:17 <bcotton_> #topic (2079510) Calendar doesn't work reliably when trying to add more than three  events which last longer than one month
18:04:18 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079510
18:04:20 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/791
18:04:21 <bcotton_> #info Proposed Blocker, gnome-calendar, NEW
18:04:23 <bcotton_> #info Ticket vote: FinalBlocker (+0,0,-3) (-bcotton, -lruzicka, -humaton)
18:05:01 <bcotton_> So I tried yesterday and this morning and I couldn't reproduce this
18:05:23 <lruzicka> I did not reproduce it either.
18:05:40 <sgallagh> By "last longer" do you mean the individual meeting is longer than a month, or it repeats for more than a month?
18:05:46 <lruzicka> Also, I believe that this has been overtested.
18:05:51 * sgallagh reads the BZ
18:06:15 <lruzicka> sgallagh, I believe it is like the meeting start in May and ends in November
18:06:27 <lruzicka> sgallagh, and it spans all over the time
18:06:29 <sgallagh> Firm -1 from me
18:06:31 <adamw> i'm -1 to this, same justification as last time. this is kinda beyond 'basic functionality' for me.
18:06:53 <lruzicka> -1 from me (as you already know)
18:06:57 <mboddu> Yeah, -1 for me as well
18:07:21 <nirik> -1
18:07:34 <copperi[m]> -1
18:07:55 <bcotton_> does anyone care to vote for FE status? personally, given the apparent lack of reproducibility, i'm inclined to skip that part
18:07:59 <sgallagh> FWIW, I'm also 0 on FE.
18:08:26 <nirik> skipping sounds good. we can reevaluate later.
18:08:39 <sgallagh> Yeah, skip FE decision
18:08:44 <lruzicka> +1 skip
18:08:49 <copperi[m]> skip
18:08:51 <mboddu> Agreed..
18:09:10 <sumantro> +1 to skip FE decision
18:09:15 <adamw> sure
18:09:28 <bcotton_> proposed #agreed 2079510 - RejectedBlocker - Other testers have been unable to reproduce this bug and it falls outside of "basic functionality"
18:09:43 <jednorozec> ack
18:09:49 <lruzicka> ack
18:09:59 <coremodule> ack
18:09:59 <mhroncok> ack
18:09:59 <sgallagh> ack
18:10:04 <adamw> ack
18:10:07 <copperi[m]> ack
18:10:08 <sumantro> ack
18:10:10 <bcotton_> #agreed 2079510 - RejectedBlocker - Other testers have been unable to reproduce this bug and it falls outside of "basic functionality"
18:10:22 <bcotton_> #topic (2079198) Editting of an existing contact creates another entry with empty content.
18:10:23 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079198
18:10:25 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/781
18:10:26 <bcotton_> #info Proposed Blocker, gnome-contacts, NEW
18:10:28 <bcotton_> #info Ticket vote: FinalBlocker (+1,0,-5) (+catanzaro, -bcotton, -lruzicka, -geraldosimiao, -coremodule, -humaton)
18:10:51 <sgallagh> -1
18:10:54 <sumantro> -1 Blocker
18:11:09 <nirik> -1 blocker
18:11:12 <sgallagh> Seems like an annoyance but the important part (the edited contact) is accurate
18:11:21 <lruzicka> -1 blocker
18:11:23 <adamw> note https://bugzilla.redhat.com/show_bug.cgi?id=2079198#c3 is kinda worse
18:11:25 <Southern_Gentlem> btw the wireless issue works on Virginia Tech Network
18:11:34 <sgallagh> I'd list this one as +1 FE though
18:11:43 <adamw> but still...probably a bit beyond my 'basic functionality' scope
18:12:17 <sgallagh> Yeah, I agree with adamw
18:12:42 <bcotton_> yeah, comment 3 is a little "well don't do that, then", although i can see valid cases where you'd want to
18:13:03 <sgallagh> Or where you don't have a choice, like attempting to merge two address books
18:13:10 <bcotton_> i remain -1 blocker, will add +1 FE on the basis of the comment 3 scenario
18:13:28 <adamw> yeah, -1 blocker, +1 FE
18:13:32 <mboddu> -1 Blocker +1 FE for the confusing thing that adamw pointed
18:13:41 * nirik is +1 FE also
18:13:48 <lruzicka> +1 to the standing proposals
18:14:04 <copperi[m]> +1 FE
18:15:19 <sumantro> +1 FE
18:15:32 <bcotton_> proposed #agreed 2079198 - RejectedBlocker AcceptedFreezeException - This falls outside of "basic functionality", but is worth fixing if possible
18:15:48 <coremodule> ack
18:16:02 <lruzicka> ack
18:16:05 <jednorozec> ack
18:16:17 <adamw> ack
18:16:38 <mhroncok> ack
18:16:39 <sumantro> ack
18:16:40 <bcotton_> #agreed 2079198 - RejectedBlocker AcceptedFreezeException - This falls outside of "basic functionality", but is worth fixing if possible
18:16:41 <copperi[m]> ack
18:16:55 <bcotton_> #topic (2079228) [abrt] gnome-contacts: folks_individual_get_personas(): gnome-contacts killed by SIGSEGV
18:16:56 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079228
18:16:58 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/782
18:16:59 <bcotton_> #info Proposed Blocker, gnome-contacts, POST
18:17:01 <bcotton_> #info Ticket vote: FinalBlocker (+3,0,-1) (+kparal, +lruzicka, +bcotton, -catanzaro)
18:18:11 <sgallagh> Yeah, I'm +1 on this. Adding a contact right after starting Contacts definitely hits my definition of "basic functionality".
18:18:30 <sgallagh> Actually, let me revise that.
18:18:56 <sgallagh> I'm not sure it would pass the "Last Blocker" test, though...
18:18:59 <sgallagh> Hard to say.
18:19:14 <adamw> i think on a typical bare metal system you have to be pretty damn quick to trigger this
18:19:18 <lruzicka> Has anyone reproduced on bare metal?
18:19:18 <adamw> let me try it quick on one
18:19:27 <sgallagh> I'm definitely +1 FE
18:19:38 <jednorozec> hm I tried it on bare metal like 20 times today without any sucess to reproduce it
18:19:49 <sgallagh> And since we have a potential fix ready, that may be sufficient since we're slipping?
18:19:50 <nirik> +1 FE, -1 blocker here I think... this doesn't happen on bare metal
18:20:09 <copperi[m]> +1 FE
18:20:16 <sumantro> +1 FE, -1 Blocker
18:20:19 <lruzicka> tried now, did not happen -> +1FE -1FB
18:20:20 <mboddu> Not happening for me, so +1 Blocker, +1 FE
18:20:21 <Southern_Gentlem> +1 FE -1 blocker
18:20:23 <jednorozec> +1 FE, -1 Blocker
18:20:33 <adamw> it likely depends on system speed
18:20:34 <mboddu> Sorry -1 Blocker, +1 FE
18:20:39 <adamw> on a really slow system it'd be easier to hit it
18:20:49 * mhroncok boots bare metal
18:20:50 <sgallagh> -1 Blocker, +1 FE
18:20:57 <adamw> on a VM on my laptop it's quite easy.
18:20:58 <bcotton_> i'm not sure "it only happens on VMs" is a good reason to reject this. if someone is running their daily driver as a VM because they have to use another OS for $reasons, we still want this to work
18:21:12 <Southern_Gentlem> cant get it to do it in a VM with min memory of 2G
18:21:38 <adamw> the window is about 20 seconds on a VM on my laptop (an xps 13)
18:21:49 <sgallagh> I can't repro on bare metal
18:22:34 <bcotton_> kparal, lruzicka are you still +1 blocker?
18:22:34 <sgallagh> Question: is it 25s from the launching of GNOME Contacts or 25s from the launching of GNOME itself?
18:22:46 <bcotton_> sgallagh: contacts
18:22:49 <adamw> bcotton_: even with a VM, it'll be power-dependent, i think. VMs on my laptop don't run very fast.
18:22:56 <sgallagh> Doesn't Contacts initialize itself behind the scenes, or am I confusing it with Calendar?
18:22:57 <adamw> Stephen Gallagher: 25s from launching contacts
18:22:58 <lruzicka> I believe, I can be +1fb with CommonBugs warning for VM users
18:23:04 <lruzicka> sorry, -1 fb
18:23:20 <adamw> oh, note, you can't do this on the first run of contacts, where it asks for what address book to use. you have to do that, quit, then run again and try ot reproduce it.
18:23:22 <bcotton_> i'm still +1 to block, but i can accept being in the minority here
18:23:36 <adamw> Stephen Gallagher: yes. that seems to be the problem. see my notes near the bottom of the bug
18:23:54 <adamw> i even wrote a sort-of fix, except kparal promptly found holes in it.
18:23:57 <sgallagh> Couldn't reproduce it on the second boot up either on bare-metal
18:24:09 <mhroncok> same here
18:25:03 <bcotton_> proposed #agreed - 2079228 - RejectedBlocker AcceptedFreezeException - This falls outside of "basic functionality", but is worth fixing if possible
18:25:35 <adamw> so yeah, this is the closest for me, but i'm broadly -1 just because i don't think people are likely to hit it. even in a slow VM, if you are typing a full name, email address, and maybe phone number, it's a bit hard to get in under the wire.
18:25:39 <adamw> ack
18:25:40 <nirik> ack
18:25:45 <sumantro> ack
18:25:48 <copperi[m]> ack
18:25:50 <jednorozec> ack
18:25:52 <lruzicka> ack
18:25:54 <mboddu> ack
18:26:15 <sgallagh> ack
18:26:22 <Southern_Gentlem> ack
18:26:31 <bcotton_> #agreed - 2079228 - RejectedBlocker AcceptedFreezeException - This falls outside of "basic functionality", but is worth fixing if possible
18:26:53 <bcotton_> #topic (2079274) Contact deletion is unreliable
18:26:55 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079274
18:26:56 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/783
18:26:58 <bcotton_> #info Proposed Blocker, gnome-contacts, NEW
18:26:59 <bcotton_> #info Ticket vote: FinalBlocker (+4,2,-1) (+kparal, +bcotton, +catanzaro, +asciiwolf, lruzicka, retiredlake9230, -geraldosimiao)
18:27:58 <Southern_Gentlem> unable to reproduce
18:28:19 <mhroncok> the behavior really seems quite silly
18:28:27 <adamw> seems similar to the calendar bug
18:28:41 <lruzicka> adamw, maybe a gtk thing?
18:28:43 <jednorozec> unable to reproduce on bare metal
18:28:54 <nirik> -1 blocker, +1 FE I don't think this is functionalty that is worth blocking over
18:29:21 <sumantro> -1 Blocker, +1 FE. I concur with Nirik
18:29:26 <adamw> this one is pretty close for me
18:29:40 <adamw> it's a contact manager. deleting a contact ought to work. that seems pretty damn basic.
18:29:49 <adamw> it's the second most basic operation, really. create and delete.
18:29:49 <mhroncok> I agree
18:29:57 <adamw> i might be +1 but waive for being late
18:30:32 <adamw> well, +1, we can waive it next week if it's not fixed.
18:31:00 <nirik> so thats +5,2,-3 ?
18:31:14 <sgallagh> It's pretty basic, but I also think it would fail the Last Blocker test
18:31:23 <sgallagh> I'd be -1 Blocker, +1 FE and +1 Common Bugs
18:31:25 <Southern_Gentlem> -1 blocker
18:31:30 <sgallagh> How often do you delete a contact anyway?
18:31:30 <jednorozec> -1 blocker
18:31:43 <adamw> Stephen Gallagher: quite often?
18:31:46 <sgallagh> My address book still lists entries from four jobs ago :)
18:31:55 <adamw> ugh, i couldn't live with that
18:31:58 <bcotton_> sgallagh: personally, never. i still have the phone number of friends who died years ago in my contacts
18:32:03 <adamw> you're out of mine if i haven't talked to you for a year :D
18:32:08 <sgallagh> (And I've been at RHT for almost a decade and a half)
18:32:39 * nirik is in the 'never delete' group too.
18:32:52 <lruzicka> we better start sending adamw notices on a weekly basis
18:33:22 <sgallagh> lruzicka: "start"?
18:33:39 <Southern_Gentlem> (doesnt use gnome, but my contact list in thunderbird is huge)
18:33:44 <bcotton_> so we have a weak majority for blocking. any one wish to change their minds one way or another?
18:33:46 <lruzicka> sgallagh, in order not to be deleted from his list
18:34:05 <sgallagh> Do we have a majority?
18:34:08 <Southern_Gentlem> bcotton_, i think its even
18:34:08 <nirik> I read +5,2,-6 ?
18:34:10 <sgallagh> I think it's a pretty even split
18:34:16 <adamw> since we're slipping, punt is a choice here. punt and hope it gets fixed anyway. the maintainer is looking at it now, anyhow
18:34:16 <lruzicka> I am not sure. For me, this looks like the same severity we have not blocked on a couple of minutes ago
18:34:24 <bcotton_> ah, i missed a couple late breaking votes
18:34:29 <copperi[m]> +1 blocker
18:34:37 <copperi[m]> * -1 blocker
18:34:45 <sgallagh> Does anyone disagree with +1 FE at least?
18:34:50 <Southern_Gentlem> copperi[m], make up you mind LOL
18:34:59 <copperi[m]> typo
18:34:59 <Southern_Gentlem> +1FE
18:35:00 <mhroncok> disagree with +1 FE, as in -1 FE?
18:35:26 <bcotton_> i'm not sure what punting would do except maybe allow us to duck the question entirely
18:35:32 <sgallagh> mhroncok: Right, I'll rephrase for clarity: Does anyone think it should NOT be accepted as a Freeze Exception?
18:35:36 <bcotton_> which is actually a good reason to punt :-)
18:35:53 <lruzicka> +1FE
18:36:12 <sumantro> +1 FE
18:36:15 <nirik> yeah, +1 FE, but punting might be wise... to avoid deadlock
18:36:31 <Southern_Gentlem> though at this point i am afraid if they fix it ,may make things worse
18:36:36 <bcotton_> i will say this in favor of blocking... if someone wants to remove a contact because that person brings up traumatic memories (e.g. abuse) and the next time they open the app that person is still there...that's not a great effect to have on our users
18:36:44 <sgallagh> FE doesn't mean we must take it
18:36:58 <nirik> bcotton_: true. ;(
18:37:11 <sgallagh> bcotton_: That... is a fair point. I still don't think it crosses the Last Blocker threshold though
18:37:54 <lruzicka> bcotton_, I agree, but in that case that person does not delete another contant shortly afterwards ?
18:38:13 <lruzicka> s/contant/contact
18:38:30 <adamw> +1 FE for sure.
18:38:46 <mhroncok> do we have a traumatic memories criterion?
18:38:52 <bcotton_> proposed #agreed 2079274 - Delay Blocker Decision, AcceptedFreezeException - We are gridlocked on whether the severity of this bug merits blocker status, but there's unanimous support for fixing it if possible
18:39:04 <mhroncok> ack
18:39:08 <jednorozec> ack
18:39:13 <lruzicka> ack
18:39:15 <sgallagh> mhroncok: Oh god, please don't bring that up again...
18:39:29 <nirik> ack
18:39:38 <sgallagh> ack
18:39:47 <copperi[m]> ack
18:40:35 <bcotton_> #agreed 2079274 - Delay Blocker Decision, AcceptedFreezeException - We are gridlocked on whether the severity of this bug merits blocker status, but there's unanimous support for fixing it if possible
18:40:46 <bcotton_> #topic (2079657) crash happens everytime when I scroll down/up to find a video
18:40:48 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079657
18:40:49 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/792
18:40:51 <bcotton_> #info Proposed Blocker, totem, NEW
18:40:52 <bcotton_> #info Ticket vote: FinalBlocker (+0,0,-3) (-lruzicka, -geraldosimiao, -humaton)
18:41:26 <nirik> so, it's 'open search bar' and try and scroll?
18:41:35 <nirik> or is there a race involved here too?
18:42:47 <adamw> i reproduced it on the first try, from the traceback it looks like there may be some kind of timing condition involved but i couldn't say what
18:42:57 * nirik can't see it here in rawhide FWIW
18:43:16 <adamw> i did what lnie said - ran totem, clikced search, typed something in the search bar, and tried to scroll
18:43:20 <adamw> it crashes about 3/4 of the way down
18:43:26 <jednorozec> not reproducible on my bare metal
18:43:30 <adamw> it likely depends on what videos you have to search from, at least
18:43:35 <adamw> you're gonna need there to be a scrol bar
18:43:39 <nirik> ah, got it.
18:43:48 <adamw> just did it again, reproduced again
18:43:53 <jednorozec> hm
18:43:57 <adamw> hadess doesn't seem overly bothered by it
18:44:08 <adamw> i'm probably -1 on my minimal interpretation of 'basic functionality'
18:44:13 <sgallagh> Just  reproduced it as well
18:44:18 <adamw> i don't really search for videos in totem. would never have noticed this.
18:44:22 <Southern_Gentlem> +1 fe -1 fb
18:44:25 <lruzicka> aaahh, I scrolled only and could not reproduce it. did not search.
18:44:29 <nirik> yeah, -1 blocker, +1 FE (but sounds like it might not be fixed in time)
18:44:39 <adamw> our hypothetical reviewer probably won't either, as there won't be anything to search.
18:44:42 <nirik> also you need enough videos
18:44:43 <sgallagh> -1 blocker, +1 FE
18:44:58 <lruzicka> -1 blocker, +1 fe
18:45:03 <sgallagh> nirik: I reproduced it by resizing the window to only fit one video at a time :)
18:45:06 <bcotton_> -1 blocker, +1 fe
18:45:06 <jednorozec> ah ok, it crashes at the end of the scroll
18:45:20 <copperi[m]> -1 blocker +1 fe
18:45:43 <jednorozec> -1 blocker, +1 FE
18:45:51 <nirik> sgallagh: yeah, the live media/new install probibly only has the wecome video tho?
18:45:56 <sumantro> -1 blocker, +1 FE
18:46:30 <mhroncok> does the FE make sense if the developer is not interested?
18:46:39 <sgallagh> Yeah, unlikely that it will get hit on the Live
18:46:45 <mhroncok> should we make it a prioritized bug instead?
18:47:18 <bcotton_> proposed #agreed 2079657 - RejectedBlocker AcceptedFreezeException - This bug falls outside "basic functionality" but is worth fixing if possible
18:47:21 <sgallagh> If the maintainer doesn't care about it, then indeed FE is meaningless.
18:47:31 <sgallagh> As for prioritized bug... I don't think it's that urgent
18:47:37 <bcotton_> if the maintainer doesn't care about it, making it a prioritized bug won't do much
18:47:39 <nirik> ack
18:47:46 <sgallagh> ack
18:47:56 <bcotton_> with an FE, even if the maintainer doesn't care, another provenpackager might be able to fix it. or not
18:47:56 <copperi[m]> ack
18:48:07 <sumantro> ack
18:48:42 <jednorozec> ack
18:49:07 <Southern_Gentlem> ack
18:49:18 <bcotton_> #agreed 2079657 - RejectedBlocker AcceptedFreezeException - This bug falls outside "basic functionality" but is worth fixing if possible
18:49:25 <bcotton_> okay, that's all of the proposed blockers
18:50:11 <bcotton_> counting the newly-accepted blockers, there are 4 accepted blockers not in VERIFIED state
18:50:20 <Southern_Gentlem> added my results to https://bugzilla.redhat.com/show_bug.cgi?id=2072070 worked in the Live and after install with RC
18:50:21 <bcotton_> does anyone wish to propose waiving all of them?
18:50:30 <bcotton_> no? okay, moving on then
18:50:35 <coremodule> including the wpa_supplicant bug?
18:50:36 <coremodule> yes
18:50:45 <coremodule> waive them all
18:50:47 <bcotton_> coremodule: yes, including the wpa_supplicant bug
18:50:49 * sgallagh blinks
18:51:04 * nirik was going to wonder if we could hero a rc3, but seems not with the other blockers.
18:51:06 <bcotton_> -1 waive them all
18:51:08 <sgallagh> bcotton_: I've been asked to raise https://bugzilla.redhat.com/show_bug.cgi?id=2069239 for discussion as well
18:51:36 <mhroncok> we just spent 1:50 accepting them, we cannot waive them
18:51:45 <bcotton_> we coulllllld
18:51:55 <mhroncok> imagine all the sunk cost
18:51:56 <adamw> i'd be okay with waiving anything but the openssl one. that i don't want to waive.
18:52:06 <adamw> (did we actually accept anything but that one? I don't think so, right?)
18:52:13 <sgallagh> no
18:52:13 <bcotton_> sgallagh, i assume this is different from the wpa_supplicant bug
18:52:20 <bcotton_> adamw: we did not
18:52:22 <sgallagh> Different but related.
18:52:27 <sgallagh> Quote: "Similar to rhbz#2072070 this might affect WPA Enterprise Wi-Fi setups and... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/34287c3a436788f43e2aab9ac428a767e0a342a0)
18:52:39 <adamw> yeah, i'm +1 FE at least for that one.
18:52:43 <sgallagh> Same
18:53:01 <bcotton_> #topic (2069239) openssl in crypto-policy LEGACY supports TLS 1.0, but not its signature algorithm rsa_pkcs1_md5_sha1 (Was: PEAP authentication failure)
18:53:14 <lruzicka> +1 fe, why not fix it and beat ubuntu
18:53:18 <nirik> +1 FE yeah... not clear if it's blocker worthy
18:53:21 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=2069239
18:53:33 <sgallagh> Yeah, I'm weakly -1 on blocker, but firmly +1 on FE
18:53:36 <copperi[m]> +1 FE
18:53:40 <bcotton_> #info Proposed Freeze Exception, Informally Proposed Blocker
18:53:44 <sumantro> +1 FE
18:53:45 <sgallagh> And the workaround is already built, so we can land it easily,.
18:53:47 <adamw> i'm 0 on blocker, but since the fix is submitted already i'm hoping if we take it as FE and push it we don't have to worry.
18:54:14 <bcotton_> 0 blocker, +1 FE
18:54:55 <Southern_Gentlem> +1 fe
18:55:00 <bcotton_> anyone want to make the case for blocking on it?
18:56:20 <Southern_Gentlem> to me they look the same
18:56:20 <nirik> 🦗s
18:56:41 <adamw> i could be persuaded
18:57:00 <jednorozec> +1 FE
18:57:12 <mhroncok> adamw: DO IT
18:57:36 <adamw> i mean, i could be persuaded to vote +1 if someone makes the case. :D
18:57:39 * mhroncok uploaded an image: (131KiB) < https://libera.ems.host/_matrix/media/r0/download/fedora.im/07737077f1f37c044ecb8a1f4bec479fa34aa9cc/image.png >
18:57:41 <adamw> but for now i'm just taking the easy path.
18:57:58 <sgallagh> It only happens in a non-default setup
18:58:04 <bcotton_> proposed #agreed 2069239 - AcceptedFreezeException - Including this fix on GA images is beneficial for users of affected WiFi networks
18:58:12 <sgallagh> Where the crypto policy has been set to LEGACY as I understand it
18:58:13 <mhroncok> ack
18:58:39 <copperi[m]> ack
18:58:40 <nirik> ack
18:58:43 <sgallagh> So it'll hit people who are following HOWTOs on connecting to weakly-encrypted WPA networks
18:58:43 <Southern_Gentlem> ack
18:58:45 <sgallagh> ack
18:58:46 <jednorozec> ack
18:58:49 <lruzicka> ack
18:59:01 <adamw> Stephen Gallagher: well, if you don't set the policy to LEGACY you *definitely* can't connect
18:59:08 <neverpanic> In #2072070, we are fixing things in the default setup, this one requires switching crypto-policy to LEGACY, which users will have to find by Googling. Plus there's a workaround available by setting OpenSSL SECLEVEL to 0 instead.
18:59:15 <mboddu> ack
18:59:19 <adamw> so this is kind of a case of requiring a less-well-known and discoverable workaround on top of an existing more well-known wokraround
18:59:41 <adamw> but yeah, that's a reasonable point why it's different
18:59:42 <sgallagh> It's hacks all the way down...
18:59:44 <adamw> ack
19:00:11 <bcotton_> #agreed 2069239 - AcceptedFreezeException - Including this fix on GA images is beneficial for users of affected WiFi networks
19:00:27 <bcotton_> #topic Current status - test matrices
19:00:28 <mhroncok> sgallagh: always has been
19:00:29 <bcotton_> #link https://fedoraproject.org/wiki/Category:Fedora_36_Test_Results
19:00:34 <sgallagh> Never claimed otherwise
19:00:45 <bcotton_> we don't have time to go into this in detail, but adamw are there any areas where we're particularly weak at the moment?
19:00:50 <sgallagh> bcotton_: coremodule did raise the waive question
19:00:58 <sgallagh> We should probably resolve it before moving on
19:01:05 <coremodule> no, I was only half-serious
19:01:07 <coremodule> if even half
19:01:21 <coremodule> we can move on
19:01:27 <coremodule> on my account anyway
19:01:34 <adamw> i think coverage is pretty good
19:01:35 <adamw> lemme see
19:02:55 <adamw> we're still missing cloud-in-real-clouds
19:03:01 <adamw> and a couple of test cases that openqa doesn't hit on cloud
19:03:28 <bcotton_> #action bcotton to nudge Cloud WG on adding some testing coverage
19:03:28 * nirik has looked at them from both sides now. </song joke>
19:03:31 <adamw> well, jlinton did them on ARM in rc2 for rc1, but nothing for x86_64
19:03:49 <bcotton_> nirik: were they in my coffee?
19:04:22 <adamw> aside from that i think we're looking good
19:04:30 <bcotton_> awesome
19:04:40 <bcotton_> and we didn't even need to make sgallagh run AD tests during the meeting
19:04:40 <nirik> I really don't know clouds at all </more song joke>
19:05:07 <bcotton_> i'm going to exert the chair's privilege and skip a section entirely since we're already over time
19:05:26 <bcotton_> #topic Go/No-Go decision
19:05:35 <bcotton_> you have 10 seconds to argue that we should be go
19:05:53 <sgallagh> I argue that we should go... home
19:05:55 <bcotton_> #agreed Fedora Linux 36 Final is NO-GO
19:05:57 <nirik> so...
19:06:02 <nirik> ah man, missed it.
19:06:03 <mboddu> I cant argue with that :)
19:06:14 <bcotton_> #info The next F36 Final Go/No-Go meeting will be Thursday, 2022-05-05 at 1700 UTC
19:06:16 <bcotton_> #info F36 Final shifts to target date #3: Tuesday 2022-05-10
19:06:18 <lruzicka> my wife is going to kill me when I tell her
19:06:46 <nirik> I was going to ask if anyone wanted to make a quick fix for the wpa_supplicant thing, spin rc3, keep the meeting open, waive all the other blockers and go on friday morning. ;)
19:07:00 <nirik> but thats ok, we can... not do that.
19:07:01 <bcotton_> i have an appointment that will conflict with the 12 May go/no-go if we slip again, so let's not do that
19:07:26 <bcotton_> #action bcotton to announce decision
19:07:28 <sgallagh> nirik: What other blockers?
19:07:29 <mhroncok> we can slip to 19 May go/no-go to solve that
19:07:38 <sgallagh> I think the wpa_supplicant is the only one we accepted
19:07:39 <bcotton_> mhroncok++
19:07:46 <adamw> nirik: i would have been open to discussing it, but i think taking the week is actually good for the selinux blockers
19:07:47 <sgallagh> (Not including the one we punted)
19:07:54 <nirik> sgallagh: here, there's 3 other ones, 1 is fixed I think, but 2 others
19:07:56 <adamw> there are two selinux upgrade blockers that have been "resolved"
19:08:13 <bcotton_> okay, thanks everyone. i think this is the longest go/no-go we've had that didn't involve taking a 30 minute testing break
19:08:15 <nirik> the 2 gnome-photos ones
19:08:18 <bcotton_> see you next week!
19:08:19 <adamw> but which are only fixed if you install an update on f35 that only just went stable
19:08:25 <mboddu> Thanks everyone
19:08:26 <bcotton_> #endmeeting