16:00:29 <adamw> #startmeeting Fedora QA meeting
16:00:29 <zodbot> Meeting started Mon Feb  7 16:00:29 2022 UTC.
16:00:29 <zodbot> This meeting is logged and archived in a public location.
16:00:29 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:29 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
16:00:34 <adamw> #meetingname fedora-qa
16:00:34 <zodbot> The meeting name has been set to 'fedora-qa'
16:00:38 <adamw> #topic Roll Call
16:00:40 <adamw> morning folks
16:00:42 * bittin is here
16:00:54 <nielsenb> I'm here
16:01:10 * cmurf[m] here
16:03:44 * kparal is partially here
16:04:03 <adamw> which part of kparal is here?
16:06:02 <cmurf[m]> the part that wants us to believe he's here
16:06:27 <adamw> excellent point, have a cookie
16:07:08 <adamw> alrighty, let's get going
16:07:12 <adamw> #topic Previous meeting follow-up
16:07:16 <adamw> what did I forget to do this week
16:07:32 <adamw> #info no action items from last meeting
16:07:39 <adamw> anyone have follow-up that wasn't an action item and won't be covered later?
16:08:05 <adamw> oh, on the default application functionality criterion, i meant to send a revised draft of that, oops. i'll do it this week
16:08:07 <adamw> (he lied)
16:09:27 <adamw> alrighty, moving on
16:09:57 <adamw> #topic Fedora 36 status and Branching
16:10:10 <bittin> branching tommorow right?
16:10:12 * coremodule is here
16:10:26 <adamw> so, we've had a rough ride with rawhide compoes but we got one today
16:10:56 <cmurf[m]> oh great
16:11:03 <bittin> and later today, todays one broke
16:11:09 <cmurf[m]> just in time for branch to take its turn
16:11:34 <lruzicka> .hello lruzicka
16:11:35 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:12:06 <lruzicka> Sorry about coming late, I lost track of time.
16:13:14 <adamw> .fire lruzicka
16:13:14 <zodbot> adamw fires lruzicka
16:13:21 <adamw> yes, branching is indeed set for tomorrow
16:13:26 * lruzicka falls down bleeding.
16:13:44 <adamw> today's rawhide compose had several fails in openqa but they look like sort of a mixed bag, no one huge bug. something's crashing in gnome. will look into it in more detail later
16:14:00 <bittin> sounds good
16:15:05 <adamw> #info rawhide composes have been off and on but are back on again now. 36 branching is scheduled for tomorrow, so look out for 36 composes to start showing up
16:15:28 <cmurf[m]> > * <@lruzicka:libera.chat> falls down bleeding.
16:15:28 <cmurf[m]> due to being fired or the impending branch fallout? 😀
16:15:53 <lruzicka> cmurf[m], on being fired :D
16:16:27 <cmurf[m]> i think branch is 2pm EST tomorrow?
16:16:50 <adamw> the time is a bit notional, i think? it usually takes releng a few hours to do everything i think
16:17:49 <cmurf[m]> yeah, i'm just thinking it might be early on Feb 9 before a 36 compose shows up?
16:19:20 <cmurf[m]> UTC time wise
16:19:28 <adamw> oh, possibly. depending on timezones too. :D
16:20:17 <cmurf[m]> yeah just didn't want lruzicka holding his breath, seeing as he's got enough on his plate with all the bleeding...
16:20:50 <adamw> hah
16:20:53 * cmurf[m] makes a note to never fire lruzicka
16:20:54 <lruzicka> hehe
16:20:58 <adamw> anyone got any other notes on f36?
16:21:03 <adamw> cmurf: just give him a band-aid first
16:21:11 <lruzicka> cmurf[m], 5 litres are a lot when on the floor
16:21:14 * bittin does not
16:22:38 * Southern_Gentlem most server rooms have first aid kits
16:22:41 <lruzicka> adamw, we shall lay down on matrices
16:23:19 <adamw> alrighty then
16:23:29 <adamw> #topic Current criteria / test case proposals
16:23:50 <adamw> so as noted above, on the default application criterion there were a couple of useful bits of feedback, i'll incorporate those and send a new draft
16:24:02 <adamw> #action adamw to send updated draft of default application criterion revision proposal
16:24:10 <adamw> non-useful feedback will be mocked and ignored
16:24:12 <adamw> :D
16:24:31 <adamw> kparal: ahoy the part of kparal that's present, what's the status on the package management proposal?
16:24:38 <bcotton> how can you both mock and ignore it?
16:25:07 <lruzicka> bcotton, don't you know adamw? he surely can :D
16:25:12 <cmurf[m]> i assume mocked then ignored
16:25:25 <cmurf[m]> but adamw has some skill
16:25:37 <adamw> cmurf: precisely
16:27:56 <cmurf[m]> blocker review at the top of the hour?
16:28:03 <bittin> cmurf[m]: yeah
16:28:16 <cmurf[m]> thx
16:28:28 <adamw> yup indeed
16:28:29 <bittin> (not attending that myself, need to buy food and take care of some stuff at home)
16:28:52 <bittin> so point 4 and 5 ?
16:29:15 * kparal is here
16:29:45 <kparal> adamw: you don't seem to be reading my matrix PMs. I pinged you that the proposal is waiting on you, basically.
16:31:58 <adamw> oh, sorry, didn't see it this morning. pms are less obvious in matrix than my irc client :|
16:32:10 <cmurf[m]> they really are, i've missed those too
16:33:06 <adamw> your additional note sounded fine to me
16:33:26 <adamw> well, it's not that they're less obvious exactly, it's that there's way too much padding in the room list so you can never fit it all on one screen
16:33:54 <cmurf[m]> should be true that "Messages in one-to-one chats" noisy ought to put up a notification...
16:34:03 <cmurf[m]> ^set to
16:34:24 <adamw> a notification is no use if the message came four hours ago while i was asleep, though.
16:34:46 <cmurf[m]> but it's different between mobile and flatpak too
16:34:50 <adamw> oh well, things to bug the webapp devs about i guess
16:35:01 <kparal> well, lruzicka's change also sounds OK to me, and is much shorter. So, take your pick and respond there, I'll then send it to desktop lists 🙂
16:36:27 <adamw> you know i like walls of text. :D
16:36:46 <kparal> alright!
16:38:20 <adamw> i'll reply to the list, then
16:38:57 <adamw> #info revised graphical package management proposal is looking good, kparal just waiting on my opinion on how to except 'power loss during update' type events
16:42:39 <adamw> anything else on proposals?
16:43:07 <lruzicka> What about the bcotton's proposal? Are we going to do it?
16:43:48 <kparal> lruzicka: which one?
16:44:10 <lruzicka> kparal, bcotton, adamw: to utilize openQA for testing if changes still apply
16:44:42 <adamw> oh, that. well. not really sure yet.
16:44:44 <lruzicka> kparal, like nano being the default editor, etc
16:44:58 <nielsenb> So, I was going to ask about that
16:45:11 <adamw> i'm not treating it as a high priority, the highest priority for me atm is to try enabling update tests for rawhide
16:45:22 <nielsenb> Wouldn't we be better served with a criteria, that basically says you can propose a blocker if a named feature gets reverted, and it breaks your use case?
16:45:44 <kparal> yes, eventually I'd like to see some Change regression testing, but probably not the top priority
16:45:47 <nielsenb> see: https://pagure.io/fedora-qa/blocker-review/issue/581
16:45:52 <cmurf[m]> interesting idea, that's simple
16:46:00 <cmurf[m]> if someone catches it manually for now, better than nothing
16:46:04 <nielsenb> Automation is great
16:46:21 <nielsenb> But really, not sure how feasible given changes can be basically anything
16:46:31 <kparal> well, not every regressed Change is important enough to be a blocker 🙂
16:46:34 <bcotton> yeah, my proposal was more about the Changes process than QA acitvities specifically
16:47:12 <kparal> we can discuss it on the test list, but I'm not sure how to judge "this is important enough" easily
16:47:28 <nielsenb> I feel like if it was important enough to go through the change process, there should at least be some recourse for people who notice it's broken later? Even if it's ultimately being told "not a big enough deal"
16:47:45 <adamw> yeah, i feel a bit unsure about a criterion like that...it goes away from the idea of the criteria being functional...
16:48:03 <nielsenb> It's been on the list, ultimately didn't go anywhere: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/WULU6UBPYJGUGIOUY33GBOWSZFVXBQZA/
16:48:11 <adamw> the blocker process is not recourse, punishment, or a mechanism for making people pay attention to bugs
16:48:11 <kparal> undergo a Change process doesn't imply we should block on it if it breaks
16:48:14 <kparal> anything can request a Change
16:48:20 <adamw> if that's the goal, then the prioritized bug process would be a better fit
16:49:13 <cmurf[m]> yeah that's valid - in which case it should be straightforward to just file a fesco issue and they can decide if the regression is bad enough to make it a blocker
16:49:18 <lruzicka> well, if there is a possibility that a change could go reversed in the next release (I did not think it would be) then we should probably pay attention to it.
16:50:18 <nielsenb> Really neither method really scales
16:50:23 <nielsenb> Inifite automated tests
16:50:35 <nielsenb> or infinite additional "test this feature manually"
16:50:48 <cmurf[m]> i think the resolved symlink missing bug is not terrible in the outcome but what expectations are when it comes to the different editions and spins - it's non-obvious whether you're getting resolved out of the box or not
16:50:51 <nielsenb> Which is why I kind of liked the wishy-washy "you noticed we broke a thing" criteria
16:51:21 <nielsenb> At least it would be a ping to document an issue in release notes?
16:51:38 <nielsenb> As opposed to like you say, you don't know what resolver you're getting
16:51:39 <cmurf[m]> i'm not sure that's adequate
16:54:16 <bittin> not sure we have time for 4: testdays but Kernel 5.16 testing went fine and running kernel 5.16.7 on my HP 655 laptop now that jforbes baked today/yesterday and it still works also 5.16 rolled out for all in F35
16:56:11 <adamw> yeah, let's continue this discussion on list or in fedora-qa room or somethinfg
16:56:28 <adamw> #topic Test Day / community event status
16:56:30 <adamw> not sure if sumantro is around?
16:56:38 <adamw> thanks for the update bittin
16:59:36 <adamw> guess not
16:59:55 <adamw> #info kernel test week went well according to bittin, we'll get a bigger update from sumantro next time
17:00:00 <adamw> #topic Open floor
17:00:20 <bittin> guess its blockers bugs meeting now for the people wanting to attend that, so cya next week
17:00:25 <bittin> don't have anything more to report
17:00:28 <adamw> any other burning issues while I start up the blocker review meeting over in  #fedora-blocker-review?
17:03:08 <coremodule> I am burning with love for the upcoming blocker review
17:03:50 <cmurf[m]> hmm i can't find the room with Element
17:05:08 <bittin> #endmeeting
17:05:11 <adamw> coremodule: i'm glad i'm not the only one
17:05:22 <adamw> cmurf: does this help? #blocker-review:fedoraproject.org
17:05:30 <adamw> bittin: you're not a chair, only i can do that :D
17:05:33 <adamw> thanks for coming folks
17:05:35 <adamw> #endmeeting