15:01:17 #startmeeting Fedora QA meeting 15:01:17 Meeting started Mon Apr 12 15:01:17 2021 UTC. 15:01:17 This meeting is logged and archived in a public location. 15:01:17 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:17 The meeting name has been set to 'fedora_qa_meeting' 15:01:22 #meetingname fedora-qa 15:01:22 The meeting name has been set to 'fedora-qa' 15:01:25 #topic Roll Call 15:01:32 morning folks, sorry again for the late notice 15:01:37 did anyone make it? :D 15:01:48 .hello2 15:01:52 bcotton: bcotton 'Ben Cotton' 15:02:57 .hello2 15:02:57 frantisekz: frantisekz 'František Zatloukal' 15:04:40 .hello2 15:04:40 coremodule: coremodule 'Geoffrey Marr' 15:04:55 .hello lruzicka 15:04:56 lruzicka[m]: lruzicka 'Lukáš Růžička' 15:05:22 well ben lives here, of course 15:05:22 * kparal lurks 15:07:29 hi kparal 15:07:50 you only adopted the #fedora-meeting. i was born into it 15:09:06 hehe 15:09:08 alrighty 15:09:10 #topic Previous meeting follow-up 15:09:42 #info no action items 15:09:56 #info we'll follow up test day stuffl ater 15:10:13 #topic Fedora 34 Final status and validation 15:10:43 #info we're currently in Final freeze, with 6 accepted blockers and several proposed, blocker review meeting is coming up right after this meeting 15:11:09 so I'm a bit concerned about the bootloader stuff 15:12:03 #info on https://bugzilla.redhat.com/show_bug.cgi?id=1938630 (re-signed bootloader bug): we got a new shim build last week, but cmurf and I have each found a significant bug in it so far 15:12:27 and pjones is apparently going to take some time off soon, which won't help 15:12:42 what significant bug? 15:13:07 the bug I found breaks boot on dell sputnik laptops with default configuration 15:13:30 the bug cmurf found, i believe, breaks boot on older macs - ones with the original "EFI" (not UEFI) implementation 15:13:38 good to know that even laptops get vaccinated these days 15:13:54 heh 15:14:12 sputnik = 'developer edition', the ones with ubuntu preloaded (they are popular among fedora users too) 15:14:51 i believe for cmurf's case we can potentially work around it in anaconda without having to redo shim, but we need to look into that, and thinking about it, that approach wouldn't help upgrades 15:15:38 Ben Cotton: do you have any further insight here? into scheudles or anything? 15:15:56 i wish! i get all of my information second-hand :/ 15:17:13 i'd fly to boston and sit on peter's desk, but the office is closed 15:18:26 curses 15:18:38 alright, well, that's where we're at as far as I know. 15:23:37 aside from that, we're getting candidates for validation and they're testing out okay aside from the known blockers 15:23:39 so please help fill out those matrices 15:27:05 any other notes on current f34? 15:28:23 #topic Outstanding proposals 15:28:54 by which i mean "ones we haven't sorted yet", not "really good ones" :D 15:29:48 #info lruzicka proposed a criterion for multiple displays - https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/K7OED5BXPTGCYHH7QHHVOUHA4R7EG5BV/ - which got a lot of feedback 15:30:08 What, no awards ceremony? 15:30:27 sadly no 15:30:32 No, it seems that it is difficult to get the interest 15:30:57 so i think the status here is that you're taking feedback for a second draft, right lukas? 15:31:17 there will be a second draft, for sure, based on the premise that we: 15:31:33 want to test ONE CARD with TWO MONITORS max. 15:32:04 this is what I have understood so far ... anything else get too complicated and unclear 15:32:27 +1 to that 15:32:59 so, I believe it is two monitors for a desktop and one external monitor for a laptop 15:33:11 sounds reasonable 15:33:11 yeah, that seemed to be the consensus 15:34:38 ok, then I will repost the draft tomorrow probably 15:34:41 lruzicka, just beware that plenty of laptops have two gpus and need both of them to drive the external display 15:35:08 frantisekz: so what would you suggest in this case? block on them or not? 15:35:47 huh, I'd suggest not to block, at this moment, stuff gets really complicated when intel and nvidia gpus need to work together... each display on different port 15:36:04 *each display on different gpu 15:36:25 frantisekz: this is exactly what I was talking about being unclear ... when I write **one card** then someone complains about above laptops, when I skip the word one, someone complains about complexity. 15:36:36 :D :D 15:37:11 I think you should explicitly say one card, no matter what will be blocking for now 15:37:14 we can expand later 15:37:24 so, I think let's stick to ONE CARD, if there are two cards which work in cooperation, that's a bonus? 15:37:54 frantisekz: got you :D 15:37:59 yeah, for now, some laptops use only the igpu for it, some both graphics cards, let's stay with one now 15:38:14 we can explore this area and expand the blocking later down the road 15:38:16 :D 15:38:25 i guess i wouldn't get into the hardware specificstoo much; one or two cards, or discrete versus integrated gpu 15:40:36 we can decide per bug basis... I am even not sure how to find out if the external display is driven by the dGPU or iGPU 15:41:26 it does feel tricky to formulate 15:41:35 like we sort of have an idea what we want but it's hard to get into words 15:42:17 i wonder if it's one we might want to get wider input on? 15:42:28 i think we want to cover wide spread bugs that affect a lot of a particular configuration, e.g. anyone using two displays can't login because bug 15:42:33 maybe from the gfx devs about what's plausible, and from devel@ or users@ about what the user expectations are 15:43:16 whereas if it's a bug pertaining to a particular gpu or combination of gpus, more likely it's a conditional blocker 15:46:39 welp, i guess we can leave the ideas with lukas to think about :) 15:47:07 the other outstanding proposal is ben's: 15:47:08 "Basic criterion proposal: g-i-s shouldn't take 2 minutes to launch" 15:47:14 that never got settled, did it ben? 15:47:27 i was just re-reading the thread 15:47:39 it doesn't seem like anyone wanted substantive changes 15:47:53 it probably shouldn't take 30 seconds 15:48:17 first time i encountered the delay i started reaching for the power button 15:48:47 there was the one comment about "displayed without error" but as you pointed out we could cover that with the "no selinux denial and no crashes" 15:49:01 i agree that 30 seconds is probably too long 15:50:08 but i wanted to be conservative in the initial pass 15:50:56 yeah, and some systems are slow 15:51:02 how would we formally measure the time? eg. I can imagine a hw config that just takes 2 minutes to load g-i-s... 15:51:25 #info the other outstanding proposal is "Basic criterion proposal: g-i-s shouldn't take 2 minutes to launch" - https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/OSN4LTQ2BSUJQL7KIB67YNIDHSLD7I5B/ 15:51:35 what about using OpenQA? It *should* perform similarly over time, shouldn't it adamw? 15:51:38 #info this proposal seems to have solid consensus and could be moved forward 15:52:15 #action bcotton to move forward with implementing this proposal 15:52:39 frantisekz: eh, it can depend on how many things run at once. and rawhide with debugging enabled is slower. and actually figuring out how long things take in openqa isn't the easiest thing 15:53:18 mhm, okay, we'll need to figure out something else then 15:53:22 hehe openqa isn't the easiest thing ... carve it into a stone 15:54:52 we might be able to figure something, though. 15:54:55 okay, let's move on 15:55:04 #topic Test Day / community event status 15:55:17 sumantro, are you around? 15:56:06 (a bit of ot, I've fixed testdays displaying internal server error in 404 cases for test events) 15:57:03 thanks frantisekz! 15:57:29 welp, i'll do it then 15:57:52 #info today is grub and shim test day - very important, so please, after blocker meeting head to #fedora-test-day to help out: https://fedoraproject.org/wiki/Test_Day:2021-04-12_Grub_and_Shim_Test_Day 15:58:13 it will be really useful to have feedback for the new bootloader updates from as many systems as posskbe 15:58:36 today also marks the start of the IoT test week: https://fedoraproject.org/wiki/Test_Day:2021-04-12_Fedora_34_IoT_Edition 15:58:44 indeedy doodly 15:58:47 that one's in #fedora-iot 15:59:16 #info tomorrow (04-13) will be virtualization test day: https://fedoraproject.org/wiki/Test_Day:2021-04-13_Virtualization 15:59:25 so please help out with all of those if possible 16:00:34 also just a note, we have an outreachy project this cycle: https://www.outreachy.org/apply/project-selection/ ("Improve Fedora QA Dashboard"), so we have folks showing up in IRC and other places who are interested in that 16:01:06 please be welcoming :D you can direct them to lbrabec or jskladan for specific info on the outreachy project 16:01:18 ok, so quickly: 16:01:21 #topic Open floor 16:01:24 any urgent business? 16:01:27 just one thing, this looks pretty ugly, I am yet to find time to test that, but anybody else is very welcome to do so: https://www.reddit.com/r/Fedora/comments/mojn18/fedora_34_beta_upgrade_freezes_entire_system/ ; https://bugzilla.redhat.com/show_bug.cgi?id=1948197 16:03:41 btw on shim test day, adamw made a couple ISO images, all you need to do to test is make a usb stick (or whatever) and try to boot from it 16:04:06 so it's kind of a risk free way of testing 16:04:19 openqa made them, i just copied them :D 16:04:29 sorry i didn't do one with the later build yet, didn't actually realize it was needed for today 16:05:58 well they are referenced in the test day page 16:06:03 and the UEFI test case 16:06:30 later build? of? 16:10:42 adamw maybe end this meeting? :D 16:13:02 #endmeeting