16:02:03 <adamw> #startmeeting Fedora QA Meeting
16:02:03 <zodbot> Meeting started Mon Nov 19 16:02:03 2018 UTC.
16:02:03 <zodbot> This meeting is logged and archived in a public location.
16:02:03 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:03 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
16:02:09 <adamw> #meetingname fedora-qa
16:02:09 <zodbot> The meeting name has been set to 'fedora-qa'
16:02:11 <adamw> #topic Roll call
16:02:17 <adamw> morning folks, who's around?
16:02:20 <bcotton> .hello2
16:02:21 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:24 <lruzicka> .hello2
16:02:25 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:02:37 * coremodule is here! Good morning!
16:02:47 <Southern_Gentlem> .hello2
16:02:48 <zodbot> Southern_Gentlem: Sorry, but you don't exist
16:03:17 * kparal is here
16:03:44 <kparal> I might need to leave in 30 minutes
16:06:28 * sumantro is here
16:06:32 <sumantro> hey all!
16:06:46 <lruzicka> Hey haw
16:07:34 <sumantro> lruzicka, how are you doing?
16:07:45 <adamw> sorry, just had to get my breakfast ready...
16:07:58 <lruzicka> sumantro, fine, thanks, and you?
16:08:04 <Southern_Gentlem> *** TESTERS needed for F29-20181119 Updated iso Please Join #fedora-respins to help **
16:08:06 <adamw> #topic Previous meeting follow-up
16:08:09 <lruzicka> adamw, bon apetit
16:08:19 <adamw> +1 southern_gentlem, everyone help him out!
16:08:47 <adamw> the respins are the semi-demi-hemi-(un)official live respins he does for each stable release, you can find them at https://dl.fedoraproject.org/pub/alt/live-respins/
16:08:57 <sumantro> lruzicka, great, thanks :)
16:08:59 <adamw> every time they get re-generated it's helpful if people can check and make sure they work
16:09:05 <Southern_Gentlem> when they are released :)
16:09:22 <sumantro> adamw, roger that!
16:09:31 <adamw> right, or join #fedora-respins for beta previews :P
16:09:37 <adamw> alrighty
16:10:26 <adamw> #info "adamw to try and move along outstanding criteria proposals towards resolution" - i actually did it this week! I put the fwraid -> final move into production and poked the printing and optical media proposals on-list for re-proposal
16:10:48 <adamw> "sumantro to send out initial call for F30 Test Days"
16:10:50 <adamw> sumantro?
16:11:03 <sumantro> yes done!
16:11:14 <adamw> great
16:11:27 <adamw> #info "sumantro to send out initial call for F30 Test Days" - this was also done
16:11:50 <sumantro> will file the tickets on pagure in next couple of hours for our regular test days
16:12:18 <adamw> great
16:12:28 <adamw> any other notes from last week, anyone?
16:13:30 <adamw> alrighty then
16:13:40 <adamw> #topic Lukas' desktop testing proposals
16:13:48 <adamw> so this week, the man himself is here :P
16:14:05 <adamw> sorry i didn't give you any detailed feedback myself yet, i've been battlin' Nu OpenQA and stuff
16:14:29 <kparal> feedback regarding those proposals?
16:14:33 <adamw> yeah
16:14:37 <adamw> it seems like generally so far there's a feeling there's good ideas in both proposals, they just maybe need tweaking a bit
16:14:42 <kparal> I talked about this with Lukas in person, and there were many different use cases for that proposal. We came up with a few things that might be good things to do, let me see if I can remember.
16:15:05 <kparal> * If you think there's an important app missing in some DE, just file a bug and ask the maintainers, you don't need any fesco-like blessing
16:15:25 <adamw> (again - this is re the proposal lruzicka sent to test@ about splitting up the 'desktop menus' test case and automating part of it, and considering 'core applications' for more desktops)
16:15:26 <lruzicka> yeah
16:15:41 <adamw> right
16:15:52 <adamw> i don't mind the idea of going and checking each desktop has functional key apps
16:15:54 <lruzicka> I wanted to be understood that my proposal was not about discarding any core apps from Workstation
16:16:00 <adamw> but we just can't get into a situation where we're blocking the release on the lxde spin or something
16:16:08 <lruzicka> adamw, exactly the last line is what I meant
16:16:24 <kparal> * We can clarify that basic functionality takes into account how many users the functionality affects, how many are likely to use that, and how critical the app is (e.g. basic functionality of nautilus is probably more extensive than basic functionality of gnome maps)
16:17:00 <kparal> * We can consider defining "important apps", which have higher QA standards, if the maintainers agree
16:17:14 <lruzicka> My idea was that we would make "a modest proposal" to the Spin SIGs to make sure they would think about making it
16:17:54 <lruzicka> and what kparal is writing seems like a good outcome to me
16:18:13 <kparal> * We currently have 3 blocking graphical DEs (GNOME, KDE, XFCE on ARM) and that is too many and we don't do a good job in making sure all apps work in them. It's probably not even possible, we'd delay the release by months, honestly. We need to do something about it.
16:19:12 <kparal> I wouldn't want to lower the standards for our current flagship, being Workstation, but for KDE and XFCE we might want to go the route of whitelisting which exact apps must work, and the rest of them being undefined (can be broken)
16:20:03 <kparal> or perhaps we can do it in a different way, but the current reality is we can't afford to file every brokeness we see in those desktops because we wouldn't be doing anything else and we'd block the release for a long time
16:20:05 <lruzicka> kparal, and if we could limit the KDE time a bit, we could check a few basic apps for other spins as well, from which others could benefit
16:20:09 <adamw> i agree there's an issue with the volume of testing required being just too huge
16:20:12 <adamw> mainly for kde
16:20:23 <adamw> it's not actually that bad for gnome or xfce as they don't stuff half the world onto their menus
16:20:31 <kparal> so we should make the criteria match our capabilities more clearly
16:20:46 <adamw> maybe we should actually talk to the desktop folks about this rather than just decide it ourselves?
16:20:55 <kparal> sure
16:21:04 <kparal> this is just brainstorming
16:21:11 <adamw> like, just lay out the problem - hey, we have this requirement we developed back in f13 or whatever, it's kind of a problem, how important is it to you, do you have any thoughts on how we could change it?
16:21:16 <lruzicka> adamw, Yes, but I first wanted to discuss it among us.
16:21:20 <adamw> sure
16:23:16 <adamw> so, did that help? :)
16:23:22 <lruzicka> unfortunately, there was not much fuzz about this so it seems like nobody really cares too much.
16:24:07 <adamw> i definitely care, i just kept not getting around to replying :/
16:24:12 <kparal> not that many people read boring proposals on a boring list ;)
16:24:18 <adamw> i think you're definitely right that it's worth trying to do something about it
16:24:20 <lruzicka> adamw, how should we now proceed? to whom shall we send it? I can pull it further ... do we want to go the way, kparal has just suggested?
16:24:35 <adamw> i think the next step would be to talk to the desktop teams
16:24:45 <adamw> honestly i think it's better to involve them early, before you have a definite idea what you want to do
16:24:58 <adamw> why not have more people involved in coming up with ideas :P
16:25:16 <adamw> rather than have an idea you're wedded to and then pitch it to other groups without giving them an opportunity to contribute
16:25:22 <lruzicka> adamw, ok ... I will try to summarize what we would like to achieve then in a short letter and send it to the SIGs
16:25:24 <adamw> that's just the way i think about it though
16:25:55 <adamw> yeah, i'd say lay out the problem (this testing just takes way too much time and thus very few people do it and very infrequently), and maybe our rough ideas of ways it could be changed, and ask for their feedback
16:26:18 <lruzicka> adamw, yeah, ok, I can do it.
16:26:22 <adamw> it might be worth explaining quickly the basic idea of *why* we have the criterion in the first place, for context
16:26:42 <adamw> the original idea behind it was that we'd noticed a lot of distro reviewers seemed to review by just booting the live image and clicking around a lot
16:26:53 <adamw> thus we didn't want them to click on something that just blew up in their face as this would lead to bad reviews
16:27:04 <adamw> we can certainly consider whether that's even true any more - distro reviews may have changed over the years
16:27:30 <adamw> anyway, sounds like we have an action item :)
16:27:58 <adamw> #action lruzicka to draft up a mail summarizing our concerns and ideas around revising desktop application testing, and send it to the desktop SIGs for their comments
16:28:02 <adamw> that OK?
16:28:14 <lruzicka> yup
16:28:27 <adamw> alrighty, thanks a lot for bringing this up
16:28:39 <adamw> #topic Optical media and printing release criteria proposals
16:28:42 <lruzicka> no problem :)
16:28:51 <adamw> so since these got poked last week, i figured we could have a topic for them in case anyone wanted to kick them around a bit
16:29:24 <adamw> we have criteria proposals that have been sorta stuck in the queue for a couple of months, one proposing to remove or restrict optical media boot requirements, one proposing to add some kind of requirement around printing
16:29:36 <kparal> I haven't yet read any updates on the list if there were any
16:29:40 <adamw> last week i poked both the proposers asking them to review feedback on the proposals and revise or re-propose as appropriate
16:29:55 <adamw> me either, but we can debate in ignorance! isn't that how it's done these days? :P
16:30:04 <kparal> love it!
16:30:06 <lruzicka> kparal, I have read everything today, but it does not seem to have a unified opinion on that matter.
16:30:09 <sumantro> adamw,I can take a shot at them
16:30:25 <adamw> sumantro: they both have proposers already
16:30:28 <kparal> from my pov, optical criteria can be dropped entirely. of course, the owners of those media should ideally agree with that
16:30:33 <adamw> so this is more just about discussion/feedback
16:30:42 <lruzicka> I believe, from what I have seen, that the guys would be fine with removing the criteria until they can burn their CDs and install from them
16:30:49 <adamw> kparal: that's a good point, though i'm not sure we even *know* who 'owns' generic netinst at this point.
16:31:13 <kparal> it's easier then, nobody can complain and claim to be the owner :P
16:33:11 <lruzicka> so, if somebody reports a bug that an ISO does not boot from a CD, will we there be people to deal with it?
16:33:17 <kparal> the time of optical media is simply gone, I think
16:33:32 <kparal> lruzicka: as usual, but it won't block the release
16:33:53 <adamw> well
16:34:04 <adamw> the thing is, if someone reports that kind of bug and it's not a release blocker...will it actually get attention?
16:34:08 <kparal> in all likelihood, the things will not be fixed that fast
16:34:14 <adamw> i know if it blocked the release, i would definitely help out with trying to diagnose/fix it
16:34:24 <adamw> if it didn't...i'd like to *think* i'd help out, but if there were five blockers at the same time...
16:34:47 <adamw> this isn't a reason to keep it on the blocker criteria, but realistically speaking, if it gets taken off them, it is somewhat more likely to stay broken if it breaks
16:34:51 <kparal> right, I just wanted to say that. we should be honest and say these bugs can very well not go fixed for a long time
16:34:56 <adamw> +1
16:34:59 <lruzicka> so, what about the "block-when-hit" mode first?
16:35:12 <kparal> what does that mean?
16:35:27 <adamw> i think he means 'we don't commit to running the test, but if someone tells us it's broken, it's a blocker'
16:35:29 <adamw> i don't like that.
16:35:37 <adamw> it just means it's more likely to pop up and bite us two days from release.
16:35:48 <kparal> I agree with adamw
16:35:53 <lruzicka> this is what stephen suggested in one of those mails .... we will block if somebody reports a bug, but we will not test on every compose.
16:35:54 <kparal> either commit to it or drop it
16:35:56 <bcotton> yeah, that's just asking for a last-minute scramble
16:36:24 <kparal> I still think the time is ready to get the criteria dropped, even with those disadvantages
16:36:34 <bcotton> out of curiousity, does anyone know the last time we had to block on the ISO boot criterion?
16:36:36 <adamw> i'd be fine with it happening.
16:36:45 <kparal> in the worst case, there will be other distro that will care about very old hw. we can't do everything
16:36:46 <adamw> bcotton: i dug the bug report out in the discussion thread, you can find it there
16:36:50 <adamw> think it was 3-4 years ago?
16:37:24 <adamw> it's fundamentally a rare thing, it's relatively *more* likely that we hit issues with usb boot/install
16:37:42 <adamw> because the images are *basically* ISOs that are fiddled with a bit to make them boot as USB sticks and on macs and things as well
16:37:54 <adamw> (rather than being *basically* bootable disk images that are tweaked to look like ISOs as well, or something)
16:38:12 <adamw> of course, if we change the criteria, maybe someone decides to change that too...but hey.
16:39:48 <adamw> ok, so, anything else on these proposals? it's fine if not, i just wanted to provide a space to talk about 'em
16:39:50 <kparal> as for printing, I'd be fine with a general clause that covers bugs breaking printing completely or for a widespread range of devices (all network printing, all usb printing, all printers from a major printer manufacturer, etc)
16:40:00 <adamw> yeah, that's more or less where i am too
16:40:08 <kparal> or perhaps gtk bug breaking printing from all gtk apps
16:40:46 <adamw> exactly what 'very common but not critical system function' stuff we cover has always been a bit random, no harm in adding printing to the bucket really
16:40:54 <lruzicka> I would support to block on Print to PDF. I do not think we should block on real printers
16:41:02 <adamw> it's gonna have to wind up having a bit of a subjective element to it which is a shame, but eh
16:41:40 <lruzicka> for example, printing in Brno is not flawless when accessed over cups-browsed, manual setting works.
16:41:46 <adamw> lruzicka: what if print-to-PDF is broken but printing on real printers is working? :P
16:42:03 <lruzicka> adamw, then we would block on that? :P
16:42:05 <adamw> yeah, adding in network printing complicates things a bit
16:42:22 <adamw> we could say 'locally-connected printers only', but these days printers out of the box tend to suggest connecting to the network rather than via usb
16:42:38 <bcotton> yeah, we want to be pretty narrow in how we define it, otherwise it's going to get really messy really quickly
16:42:41 <bcotton> printers are evil
16:43:28 <lruzicka> I agree, bcotton
16:44:26 <kparal> that's why I defined it as 'all networking printing broken'
16:44:27 <lruzicka> When Print to PDF works, at least users can send it out and print elsewhere
16:44:49 <kparal> or perhaps 'most'. up to a judgment call during the meeting
16:44:56 <adamw> kparal: yeah, i think i'm with you, in that we treat it a bit like we treat fwraid
16:45:04 <adamw> if we can make it work on *one* system, it's probably not a blocker
16:45:38 <kparal> regarding 'print to pdf', I'm not sure whether we should explicitly block on that
16:47:47 * jlanda is late but here (reading the logs)
16:48:00 <lruzicka> well, but we need some criteria
16:48:13 <bcotton> kparal: if we don't block on that, then i don't think we should block on _anything_ printing related
16:48:15 <adamw> we don't need to decide 'em right here
16:48:22 <adamw> but folks with solid ideas, please send them to the list discussion
16:50:06 <adamw> #topic Open floor
16:50:55 <adamw> so, i have a couple of quick openqa news items: i'm working on updating to the latest upstream openqa (or something close to it), that should be coming to staging soon and production a bit later...and we're getting some new openqa worker machines soon, thanks very much to smooge, which should increase x86_64 test capacity quite a lot
16:52:17 <lruzicka> *applause*
16:52:43 <jlanda> I wanna bring a discussion from fc29 retrospective meeting. We had some complains about selinux denial notifications on the meeting, and the fact is that once f27 goes EOL our current notification denial c
16:52:47 <adamw> #info openqa upgrade coming to staging soon (hopefully), and we will be getting new openqa x86_64 worker machines soon also
16:52:57 <jlanda> ar, sorry, I didn't want to ppst it yet
16:53:09 <adamw> *jlanda was eaten by a grue*
16:53:56 <jlanda> and the fact is that once f27 goes EOL our current notification denial criteria will just block troubleshooting app from being default installed on gnome workstation
16:54:19 <adamw> sorry?
16:54:30 <jlanda> since f27 was the last one that it had it, and since the release criterias just blocks n-2 upgrades
16:55:04 <jlanda> no throubleshooting applet -> no notifications -> no blocking from them
16:55:14 <kparal> setroubleshoot is no longer installed by default
16:55:27 <kparal> (just clarifying)
16:55:30 <lruzicka> how to hide if selinux has issues :D
16:55:32 <jlanda> ty
16:55:48 <jlanda> my train connectivity is worst than a 28.8kbps modem
16:56:03 <jlanda> so, we should do something with that criteria
16:56:39 <jlanda> or propose to read throubleshotting applet to wks, or block on selinux denials of default packages and not on the notification itself
16:56:48 <jlanda> or drop it, or whatever :D
16:57:10 <kparal> btw, I don't know whether setroubleshoot is active by default or not on KDE and XFCE
16:57:18 <kparal> *in
16:57:31 <kparal> let's not forget we don't only test GNOME
16:57:34 <lruzicka> let me check
16:57:43 <adamw> ah, right.
16:57:59 <adamw> the same criteria covers crash notifications, right?
16:58:14 <adamw> so...overall, i think it's still more or less fine
16:58:24 <lruzicka> Fedora basic desktop has ENFORCING
16:58:34 <lruzicka> KDE will have the same
16:58:48 <adamw> the point is whether the *app that displays notifications of selinux denials* is installed by default
16:58:52 <adamw> on workstation it no longer is
16:59:10 <lruzicka> ahh, cant see that
16:59:17 <adamw> thus, denials in themselves will no longer be blocking on ws, as you won't get denial notifications ootb
16:59:28 <adamw> of course, if the denial breaks something that's actually release-blocking functionality, that's still blocking
16:59:47 <jlanda> adamw: exactl
17:00:09 * jlanda is on another tunnel, I'll stop to try writing, this is useless :D
17:00:31 <adamw> well, we're out of time
17:00:34 <adamw> but thanks for bringing it up, jlanda
17:00:50 <adamw> i think the criterion is probably OK for now as it also covers crashes, and covers KDE and Xfce as kparal pointed out
17:01:16 <kparal> that latter we don't know
17:01:31 <adamw> i'm like about 75% sure it's there on kde. :P
17:01:44 <lruzicka> adamw, Everything is on KDE.
17:01:54 <jlanda> I'll test with a respin asap
17:02:00 <adamw> yeah, it is
17:02:03 <adamw> it's in admin-tools
17:02:07 <adamw> and admin-tools is in kde-desktop-environment
17:02:14 <adamw> so, there we go.
17:02:31 <kparal> the package is there, but does that applet work?
17:02:56 <jlanda> let force some denials on kde respin to test it :D
17:03:11 <adamw> kparal: iirc it does
17:03:12 <adamw> anyhoo
17:03:12 <jlanda> since everything use to be broken on kde
17:03:15 <adamw> =)
17:03:19 <adamw> thanks for coming, everyone
17:03:27 <kparal> thanks
17:03:40 <jlanda> thanks, see you
17:03:45 <lruzicka> thanks
17:03:48 <lruzicka> have a nice time
17:04:20 <adamw> #endmeeting