15:03:16 #startmeeting Fedora QA Meeting 15:03:16 Meeting started Mon Oct 28 15:03:16 2019 UTC. 15:03:16 This meeting is logged and archived in a public location. 15:03:16 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:16 The meeting name has been set to 'fedora_qa_meeting' 15:03:20 #meetingname fedora-qa 15:03:20 The meeting name has been set to 'fedora-qa' 15:03:24 #topic Roll call 15:03:28 Happy Release day tomorrow! 15:03:30 ahoyhoy, who's around for qa meeting fun? 15:03:38 .hello2 15:03:39 bcotton: bcotton 'Ben Cotton' 15:03:41 .hello2 15:03:41 tablepc: tablepc 'Pat Kelly' 15:03:55 .hello2 15:03:56 coremodule: coremodule 'Geoffrey Marr' 15:04:28 * cmurf is joining from Lille, France 15:05:20 tablepc: correct. if you have questions/comments, let's move that conversation to #fedora-magazine 15:05:30 .weather 15:06:00 well too bad, because there will be ZERO FUN 15:07:20 coremodule it might want a zip or city 15:07:32 #topic Previous meeting follow-up 15:08:15 #info "adamw to check with desktop team that they're confident about resolving all the outstanding GNOME-related blockers" - I did that, and hey, in the end, turns out they did get resolved 15:08:36 #info "adamw to go ahead and add the basic desktop background criterion to 'automatic blockers' as that proposal received no objections" - I think I forgot to do that, I'll do it this week 15:08:44 #action adamw to go ahead and add the basic desktop background criterion to 'automatic blockers' as that proposal received no objections 15:08:48 any other follow up, folks? 15:09:56 * cmurf is super impressed by all the hard work to make the release happen 15:10:12 me too! 15:11:06 Me too! You folks always manage to make it happen! 15:11:25 allllrighty then 15:11:38 #topic Fedora 31 status and final actions 15:11:47 so, as we just said - thanks to everyone for helping get F31 ready! 15:12:01 #info many thanks to all who helped test F31 and participate in the blocker process 15:12:16 #info the release is set for tomorrow, 2019-10-29 15:13:12 it looks like the upgrade fixes for F29 and F30 went stable over the weekend, so that's sorted out 15:13:37 *whew* 15:13:56 #info the libdnf, gnome-software and dnf-plugins-extras updates with the workarounds for upgrades when libgit2 module is enabled went stable for F29 and F30 over the weekend, so that AcceptedPreviousReleaseBlocker is addressed 15:14:20 i believe that means all we have to worry about is the common bugs page, which i'll work on today 15:14:50 #info please tag any unfixed bugs you believe are likely to pop up for a significant number of f31 users with the 'CommonBugs' keyword 15:15:17 The Gnome folks are even making progress on my favorite big. 15:16:24 https://bugzilla.redhat.com/show_bug.cgi?id=1694782 15:16:26 yeah, i saw that 15:16:30 i just updated the link and stuff 15:16:32 thanks for keeping an eye on it 15:18:17 so, anyone have anything else on f31? 15:19:04 Just installations :) 15:19:35 heh, sounds good 15:19:39 alrighty then 15:19:45 #topic Criteria proposals status 15:20:02 so, yeah, these sort of got dropped when f31 heated up, but we still have a few lying around we need to decide what to do with 15:20:45 the main one is the idea to drop the xen criterion, which morphed into 'make the ec2 requirements a bit more specific, and cover xen-based ec2 instances' 15:21:22 if no-one minds, i think at this point there's enough info lying around in the existing threads that i think i can put together a comprehensive proposal, so i can do that this week 15:21:59 the irony 15:22:16 it started as "remove xen", now it's "better define xen and add more tests" 15:22:37 which no one will run 15:22:57 not really 15:23:03 ec2 is a thing people actually use 15:23:06 ...unlike xen :P 15:23:21 yeah and there are things in AWS that still use xen I guess 15:23:30 yeah, that's the main thing we found out from the proposal 15:23:35 that there are still quite a lot of xen-based ec2 instance types. 15:24:09 i'm gonna propose we simply pick one nitro instance type and one xen instance type and require that fedora boot on both of those, and have each as a column in the Cloud matrix 15:24:12 i think that ought to cover it 15:24:15 sound good? 15:24:23 sure 15:24:26 I'm not sure how to recruit more help - my email on devel@ about dropping the xen criterion didn't get any replies 15:24:38 it's easy enough to spin up a xen ec2 instance 15:24:46 so it's still a bit tenuous, supporting xen 15:25:31 maybe go directly to xen users or devel lists next time around? *shrug* 15:26:37 well, the idea is to focus much more on 'supporting ec2' than 'supporting xen' 15:26:49 understood 15:26:57 the word 'xen' isn't going to appear anywhere, it's just going to be two ec2 instance types 15:27:45 #action adamw to refresh the proposal to replace the xen criterion with more specific ec2 requirements (including requirement for a xen-based instance type to work) 15:27:59 ok, so other than that...we have the 'toggle key criterion', proposed by bcotton 15:28:16 Is there anything newer and more loved that does the same things xen does? 15:28:16 last status on that was that kparal suggested modifying it based on our discussion in a go/no-go meeting 15:28:47 tablepc: sure, kvm. and also virtualbox which is what most people actually use, though we don't block on it. 15:29:03 bcotton: did you see kparal's mail? 15:29:15 adamw: not that i recall, let me look 15:29:40 ah, yes i did 15:29:52 i think the light state is important from a user perspective 15:30:06 but i understand that it's a little more difficult, so i won't object to dropping it 15:31:12 can you send a modified proposal? or do you want kparal to take the bullet? :P 15:31:19 i can do it 15:32:08 thanks 15:32:21 #action bcotton to refresh toggle key criterion proposal with modification suggested by kparal 15:32:56 we also have a proposal by dustymabe to add some container requirements to the criteria, under the topic "Proposing new release criteria" 15:33:03 Is it that the software that touched the keyboard is several layers deep, or is it the some keyboards don't report the light status? 15:33:12 i believe that one's currently 'waiting for feedback', so if folks can read and respond that'd be good 15:33:35 tablepc: it's more that lots of layers get a vote, including the firmware, and i think there's no mechanism for the OS to ask "what state is the light *currently* in" 15:34:24 (there's also fun stuff like, what do you do about VMs? when someone hits 'caps lock' in a VM do you toggle the light on the host system keyboard? if they make a different window active do you try and flip it again? stuff like that) 15:35:52 i think years and years ago the lock toggles were actually handled *in the keyboard itself*, i.e. it just sent different keycodes to the computer when they were toggled, so it also handled the light status itself and everything stayed in sync fine. but that isn't how it works any more. anyway, dubious computing history lesson ends here! 15:36:56 I bet that's why mine always works. I always use those nice old Big IBM keyboards 15:37:06 yeah i've got an apple keyboard without a caps lock, and on Windows and macOS the keypad just works and I'm a occasionally slightly frustrated it doesn't work on Fedora 15:37:12 tablepc: so do i, but all the lights stay on all the time on mine for some reason. annnnyhoo 15:37:42 on the image size criterion, the 'report bug when image is oversize' mechanism i hooked up seems to be working, so that *should* mean we can keep the criterion at Beta for now 15:38:15 does that set it as an automatic blocker? 15:38:15 #info dustymabe proposed some container requirements under the topic "Proposing new release criteria", please read and respond to those 15:38:28 cmurf: it automatically proposes the bug as a blocker if it's a blocking image. 15:38:37 that is awesome 15:38:42 automatically accepting is harder, but not necessary. 15:39:17 right, it ends up on the board at least and then when anyone sees it, they can just white board approve it under the automatic blocker policy 15:39:39 #info proposed move of 'image size' criterion to Final is on hold as we expect the new mechanism for automatically reporting bugs when images are oversize to help us handle it properly at Beta 15:40:24 we also have the printing proposal from like a year ago hanging around, still 15:41:44 the most recent draft of the proposal on 2019-02-28 got a couple of responses from cmurf 15:42:10 #action adamw to follow up on the printing criteria proposal and ask sgallagh if he thinks we should push it out as-is 15:42:22 seems reasonable 15:42:22 I finally figured how I could get gnome to set up my printers thought I'll still likelu use CUPS 15:42:57 i think that's everything on the pending list 15:43:01 I think the idea is to print to any IPP Everywhere capable printer (possibly some minimal version for that), and perhaps the open question is what is the test 15:43:03 any other notes before we move on? 15:43:25 nope 15:43:42 I'm guessing tht IPP Everywhere is what's causeing gnome set up problems. 15:43:54 *shrug* could be 15:44:30 It fines my printer but won't install it. I have to removed the one it found and go through add printer then it works.\ 15:44:35 that capability is built into CUPS, it should just work, but there are version specific issues when it comes to IPP Everywhere over USB that I don't fully understand 15:44:55 #topic Test Day / community event status 15:45:02 interesting, so like a discovery and autosetup problem 15:45:47 #info it seems we are missing sumantro this week, so let's table this unless anyone has notes 15:45:47 I guess I should write a gnome issue on it. 15:47:02 #topic Open floor 15:47:05 welp, that's all I ahd 15:47:18 anyone got other issues, concerns, notes, future lotto numbers? 15:48:10 I'll send that proposed change on disk checking back to the list. I think it got lost in the release efforts. 15:48:27 sorry, which proposal was that? i didn't mean to leave any out 15:48:54 The one to be sure we're getting good dismounts. 15:49:12 ah, ok. yes, please resend if it didn't get any responses 15:49:16 On restarts 15:49:33 ideally include the string 'propos' and/or 'criter' in the topic, as those are what i search for when looking for criteria proposals :P 15:49:43 tablepc: didn't see that, hmmm - devel@ or test@ 15:50:10 Maybe three months back. 15:51:09 I'll send it again later today 15:51:43 thanks 15:52:10 you know...if we had the criteria in docs.fp.o, we could do proposals as pull requests ;-) 15:54:22 i still don't really see how that would be any better 15:55:12 let me do a little more unrelated work and then i'll be able to better make the case :-) 15:55:17 well, changes would be discrete 15:55:49 whereas with wiki history the changes are monolithic, based on date - takes some iteration to figure out specific changes, who and why 15:55:59 eh? 15:56:21 each wiki change is a single thing that's tracked on the history page 15:56:23 with a description 15:56:49 I can do into the wiki and change every other word to German, and it'll accept that as a single change on this date, assigned to me 15:57:00 easy to revert but it's not a discrete change per criterion 15:57:07 i mean, you can also make a git commit that changes everything in a repository 15:57:51 the git commit workflow is inherently narrowly focused in practice 15:58:13 Maybe a system like Magazine uses to start a proposal and track comments. 15:58:22 but whatever, i don't really care 15:58:27 adamw is the gatekeeper 15:58:39 the gatekeeper gets to choose the method 15:58:40 :D 16:01:11 welp, that's our time, folks 16:01:13 thanks for coming 16:01:21 Have a Great Day! 16:01:41 #endmeeting